What is the accepted practise for returning from boolean methods - methods

Okay, this is a simple question, but I'd like some oppinions on the correct practice here. I am not looking at this for performance concerns, because CPU's are so powerful that this wouldn't make any perceivable difference unless called without a looping contruct with thousands of iterations. I just want views on what is the accepted standard.
I have a method that bascially just does a check returns a boolean. However, there are numerous ways to implement this.
Here is how I would normally implement this.
public bool CanUndo()
{
if (_nCurrentUndoIndex > 0)
return true;
else
return false;
}
However, it is often frowned upon to return from the middle of a method. The only time I normally do this is when performing a check on a form submission like this.
if (String.IsNullOrEmpty(firstName.Text))
{
MessageBox.Show("Please enter a first name", "Incomplete");
return;
}
I consider that acceptable.
Back to the undo question, an alternative way to code it would be this.
public bool CanUndo()
{
bool returnVal;
if (_nCurrentUndoIndex > 0)
returnVal = true;
else
returnVal = false;
return returnVal;
}
This however unncessarily allocates a variable and is more verbose code. Another option would be.
public bool CanUndo()
{
bool returnVal = false;
if (_nCurrentUndoIndex > 0)
returnVal = true;
return returnVal;
}
This is more streamlined as it gets rid of the else. However, if the value is true is makes an unneccesary assignment by initializing it to false.

public bool CanUndo () {
return _nCurrentUndoIndex > 0;
}
Personally I don't have a problem with returning from the middle of a method. It complicates cleanup code for C functions but with RAII that argument disappears.
I prefer to exit as soon as is suitable otherwise you get
if (x) {
if (y) {
if (z) {
complete
}
}
}
rather than
if (!x)
return
if (!y)
return
if (!z)
return
complete
This way you avoid nesting, wide lines (horizontal screen space is expensive, vertical space is cheap) and you always know that if you're still in a function then you're not in an error path. Code which works well with this design also works well with exceptions, which is very important.

you should always contract boolean returns to their logical aquivalent, because this is much easier to read for developers, it is faster to write for you and it get contracted by the compiler anyways.
consider an expanded or:
if (a == 1)
return true;
else if (a == 2)
return true;
else if (a == 3)
return true;
else
return false;
and the reason should become obvious when you compare it to the contracted version
return (a == 1) || (a == 2) || (a == 3)

public bool CanUndo()
{
return (_nCurrentUndoIndex > 0);
}

Related

Sudoku solver with backtracking can't always detect multiple solutions

This is the code I wrote to check if there are multiple solutions to a KenKen puzzle (Similar to Sudoku). Technically it should return true if there are 2 solutions, but it doesn't appear to work because of a logic error in the algorithm.
I can't seem to find the error and after spending a whole day debugging the whole thing step by step I feel like I'll never find out what's wrong.
The code can solve the puzzle without any problems but it doesn't always seem to detect when there are multiple solutions, which is just weird.
boolean solutionFlag = false;
static boolean backtrackingUniqueSolution(int startIndex) {
for (int i=1; i<=sudokuGridElements.length; i++){
sudokuGridCells[startIndex] = i;
if(checkConditons()){
if(endOfBounds || backtrackingUniqueSolution(startIndex + 1))){
if(!solutionFlag){ //Used to "count to 1"
solutionFlag = true;
} else {
return true; //Should return true only after it finds the second solution
}
}
}
sudokuGridCells[startIndex] = null;
}
return false;
}
When you find the first solution, you set the flag, but return false, so that you don't know whether a solution was found further up the recursion stack. The flag tells you that, but you must still look for a second solution to get your answer.
You should distinguish between actually finding a solution when the last cell is reached and cutting recursion short when you already have found a second solution. In the first case, do the delayed counting via the flag. In the second case, just return true if a second solution was found, that is when the recursive function has returned true.
boolean solutionFlag = false;
static boolean multiSolution(int startIndex) {
for (int i = 1; i <= sudokuGridElements.length; i++) {
sudokuGridCells[startIndex] = i;
if(checkConditons()) {
if (endOfBounds) {
if (solutionFlag) return true;
solutionFlag = true;
} else {
if (multiSolution(startIndex + 1)) return true;
}
}
sudokuGridCells[startIndex] = null;
}
return false;
}
(You could get rid of the non-local state flag, if you made the function return an integer or enumerated value which tells you whether no, a single or many solutions were found.)

Best way to test if all elements of an array/list satisfy a condition

I would like to test if all elements in an array (or list) satisfy a condition. But I would like to do it in the cleanest and most optimized way I can.
I used to do something like this (exemple in c++) :
vector<unsigned> vct; // put anything in it
bool verified = true;
for (unsigned elmt: vct) {
if (!mycondition) {
verified = false;
break;
}
} // then use verified to check if condition is satisfied for each element
But then someone told me that you usally want to initialize verified to false and then turn it to true. This made me do :
vector<unsigned> vct; // put anything in it
bool verified = false;
unsigned count = 0;
for (unsigned elmt: vct) {
if (mycondition) {
++count;
}
}
if(count == vct.size())
verified = true; // then use verified to check if condition is satisfied for each element
But this solution does not seem optimized at all because we use a counter and we have to loop through all the elements while the first solution stopped as soon as it finds a "bad" element.
So here is my question.
What is the cleaner and most optimized way to test if all elements in array satisfy a condition ?

Methods, more than one return?

I have the following method:
From what I learned methods which are not voids need a return. For the following examples I can see two returns, once after if(), and one at the end.
For this example if String s is not a digit it will return the boolean as false. Which makes sense. If it is a digit then it will check whether it is in the interval. I guess I am confused regarding whether we can have multiple returns in such cases and what the limitations are, if there are any. thank you.
private boolean ElementBienFormat(String s) {
for (int i = 0; i < s.length(); i++) {
if (!Character.isDigit(s.charAt(i))) {
return false;
}
}
int n = Integer.valueOf(s);
return (n>=0 && n <=255);
A method will "quit" (return) when control reaches a return. So in this case as soon as a character is not a digit in the input String control will go back to the caller (with the appropriate value).
boolean success = ElementBienFormat( "a" ); // <-- control would go back here with the value of false.
Another quick note is that a void method can have multiple return statements as well
private void Method( int n )
{
if( n < 0 )
return;
//...
//implicit
//return;
}

Is there a tool that computes what happens in a method based on the values of the args passed in?

I'm working on a legacy app that is not just spaghetti, but turns to egg shells when broken (Humpty Dumpty syndrome), where figuring out what is going on as the code meanders around like a drunken sailor in Old Manila is like trying to find a poodle in a smokestack.
As an example, here is a method that I must grok; this is just the first part of it:
private void InitializeBackgroundThread( LoginStatuses loginStatus, string DialogCap )
{
try
{
double pause = 1;
int wait = 250;
ProgressChangedFlag = false;
ProgressChangedIndex = 0;
pc = new PendingCommands( pause, wait );
PendingCommands.ProcessCommands = true;
if (!((loginStatus == LoginStatuses.LoginVendors) || (loginStatus == LoginStatuses.LoginInventory)))
PendingCommands.Processing = false;
PendingCommands.Timeout = false;
Util.StopCancelRequested = false;
if( timeOut != "" )
pc.timeOut = timeOut;
if (!((loginStatus == LoginStatuses.LoginVendors) || (loginStatus == LoginStatuses.LoginInventory)))
{
InitializeBackgroundThread_CCRLoginTerminate (true);
InitializeBackgroundThread_CCRTimerExceeded (true);
InitializeBackgroundThread_CCROnline (true);
}
if (loginStatus == LoginStatuses.LoginVendors)
{
InitializeBackgroundThread_CCRCommandConfirmedGetsites (false);
InitializeBackgroundThread_CCRCommandConfirmed (false);
InitializeBackgroundThread_CCRCommandConfirmedSitesetup (true);
}
else if (loginStatus == LoginStatuses.LoginSitesData)
{
InitializeBackgroundThread_CCRCommandConfirmed (false);
InitializeBackgroundThread_CCRCommandConfirmedSitesetup (false);
InitializeBackgroundThread_CCRCommandConfirmedGetsites (true);
}
else
{
InitializeBackgroundThread_CCRCommandConfirmedSitesetup (false);
InitializeBackgroundThread_CCRCommandConfirmedGetsites (false);
InitializeBackgroundThread_CCRCommandConfirmed (true);
}
InitializeBackgroundThread_CCRProgress (true);
InitializeBackgroundThread_CCRProgressChanged (true);
InitializeBackgroundThread_CCRProgressComm (true);
Now I can "deskcheck" it by going through it with a notepad, asking myself, "Okay, what will happen - which variables will be assigned which values, and which methods will be called - if loginStatus is "AllQuiet"? What if loginStatus is "SNAFU"? Etc. etc. ad nauseum.
Wouldn't it be great if a tool could eat this spaghetti right up and spit out a report such as:
*With a loginStatus of "AllQuiet"
PendingCommands.Processing is set to true.
InitializeBackgroundThread_CCRProgressChanged is called.
...
With a loginStatus of "SNAFU"
(etc.)*
This would be a "killer" debugging/sanity check tool. I know there are code coverage tools, but are there any that are this sophisticated?
This isn't code coverage, which simply tracks what code gets executed if you run a specific test.
What you want is something like a cross between program slicing ("show me everything downstream/upstream from some code point" aka 'a slice' http://en.wikipedia.org/wiki/Program_slicing),
and partial evaluation ("show me what this code looks like if I assume some value is a specific constant" http://en.wikipedia.org/wiki/Partial_evaluation). And you want it to display the result superimposed on top of your actual code (e.g. boldface the selected part) to see your focus.
Yes, that would be wickedly nice tool.
No, I don't know of any. There are program slicers for C and C++ (See http://www.grammatech.com/research/technologies/codesurfer). I don't think they have the partial evaluation part, but I think they do have some other options to minimize the size the slice being inspected.

Redundant code constructs

The most egregiously redundant code construct I often see involves using the code sequence
if (condition)
return true;
else
return false;
instead of simply writing
return (condition);
I've seen this beginner error in all sorts of languages: from Pascal and C to PHP and Java. What other such constructs would you flag in a code review?
if (foo == true)
{
do stuff
}
I keep telling the developer that does that that it should be
if ((foo == true) == true)
{
do stuff
}
but he hasn't gotten the hint yet.
if (condition == true)
{
...
}
instead of
if (condition)
{
...
}
Edit:
or even worse and turning around the conditional test:
if (condition == false)
{
...
}
which is easily read as
if (condition) then ...
Using comments instead of source control:
-Commenting out or renaming functions instead of deleting them and trusting that source control can get them back for you if needed.
-Adding comments like "RWF Change" instead of just making the change and letting source control assign the blame.
Somewhere I’ve spotted this thing, which I find to be the pinnacle of boolean redundancy:
return (test == 1)? ((test == 0) ? 0 : 1) : ((test == 0) ? 0 : 1);
:-)
Redundant code is not in itself an error. But if you're really trying to save every character
return (condition);
is redundant too. You can write:
return condition;
Declaring separately from assignment in languages other than C:
int foo;
foo = GetFoo();
Returning uselessly at the end:
// stuff
return;
}
I once had a guy who repeatedly did this:
bool a;
bool b;
...
if (a == true)
b = true;
else
b = false;
void myfunction() {
if(condition) {
// Do some stuff
if(othercond) {
// Do more stuff
}
}
}
instead of
void myfunction() {
if(!condition)
return;
// Do some stuff
if(!othercond)
return;
// Do more stuff
}
Using .tostring on a string
Putting an exit statement as first statement in a function to disable the execution of that function, instead of one of the following options:
Completely removing the function
Commenting the function body
Keeping the function but deleting all the code
Using the exit as first statement makes it very hard to spot, you can easily read over it.
Fear of null (this also can lead to serious problems):
if (name != null)
person.Name = name;
Redundant if's (not using else):
if (!IsPostback)
{
// do something
}
if (IsPostback)
{
// do something else
}
Redundant checks (Split never returns null):
string[] words = sentence.Split(' ');
if (words != null)
More on checks (the second check is redundant if you are going to loop)
if (myArray != null && myArray.Length > 0)
foreach (string s in myArray)
And my favorite for ASP.NET: Scattered DataBinds all over the code in order to make the page render.
Copy paste redundancy:
if (x > 0)
{
// a lot of code to calculate z
y = x + z;
}
else
{
// a lot of code to calculate z
y = x - z;
}
instead of
if (x > 0)
y = x + CalcZ(x);
else
y = x - CalcZ(x);
or even better (or more obfuscated)
y = x + (x > 0 ? 1 : -1) * CalcZ(x)
Allocating elements on the heap instead of the stack.
{
char buff = malloc(1024);
/* ... */
free(buff);
}
instead of
{
char buff[1024];
/* ... */
}
or
{
struct foo *x = (struct foo *)malloc(sizeof(struct foo));
x->a = ...;
bar(x);
free(x);
}
instead of
{
struct foo x;
x.a = ...;
bar(&x);
}
The most common redundant code construct I see is code that is never called from anywhere in the program.
The other is design patterns used where there is no point in using them. For example, writing "new BobFactory().createBob()" everywhere, instead of just writing "new Bob()".
Deleting unused and unnecessary code can massively improve the quality of the system and the team's ability to maintain it. The benefits are often startling to teams who have never considered deleting unnecessary code from their system. I once performed a code review by sitting with a team and deleting over half the code in their project without changing the functionality of their system. I thought they'd be offended but they frequently asked me back for design advice and feedback after that.
I often run into the following:
function foo() {
if ( something ) {
return;
} else {
do_something();
}
}
But it doesn't help telling them that the else is useless here. It has to be either
function foo() {
if ( something ) {
return;
}
do_something();
}
or - depending on the length of checks that are done before do_something():
function foo() {
if ( !something ) {
do_something();
}
}
From nightmarish code reviews.....
char s[100];
followed by
memset(s,0,100);
followed by
s[strlen(s)] = 0;
with lots of nasty
if (strcmp(s, "1") == 0)
littered about the code.
Using an array when you want set behavior. You need to check everything to make sure its not in the array before you insert it, which makes your code longer and slower.
Redundant .ToString() invocations:
const int foo = 5;
Console.WriteLine("Number of Items: " + foo.ToString());
Unnecessary string formatting:
const int foo = 5;
Console.WriteLine("Number of Items: {0}", foo);

Resources