Bool expression??
-
It's not THAT horrible. Yes, it's not exactly elegant, but sometimes this is done to make things clearer to other coders (especially less-experienced ones).
It IS that horrible when you join a project and the other "experienced" consultant is writing a pile of redundant crap like that: if(x == true) { control.Enabled = true; } else { control.Enabled = false; } The above adds an extra comparison operation in addition to being ugly. Besides, as someone already mentioned, How will the juniors ever progress? Forgiveable for the OP though :) The project i joined has a metric buttload of that garbage. Even worse is these guys "architected" classes without methods (can you say pre-OOP structures boys & girls?) and then created a function library (which they called a "fascade" and is NOTHING like the fascade design pattern) where you pass in an instance of this methodless "class" to the method of a fascade class to do work on it (i.e. persist it). The reasoning? They thought adding methods to the class would make it too slow. It has been a rollercoaster of emoticons. :omg: :wtf: :mad: :sigh: :(( :rolleyes: e.g. class Person { public string FirstName; public string LastName; } class PersonFascade { public void InsertPerson(Person p) { /* do stuff */ } public void UpdatePerson(Person p) { /* do stuff */ } public void DeletePerson(Person p) { /* do stuff */ } }
-
The senior programmer could place comments like this:
if (x == true) return true; else return false; // the previous snippet could be replaced with // return x; // but i have chosen not to use this so that junior-programmers // can understand how two different values can be returned by one single function // // To other senior programmers. Please leave the previous snippet or replace it by // another snippet that would clarify the problem even bettercodito ergo sum
Then it should be
return x ;
// If I ever catch any of you writing it as
//
// if (x == true)
// return true;
// else
// return false;
//
// I'll have you tied to an anthill and covered in honey! -
It's not THAT horrible. Yes, it's not exactly elegant, but sometimes this is done to make things clearer to other coders (especially less-experienced ones).
Great point. Never thought of it that way. But it wasn't a sennior programmer making things clearer, nor a junnior one making misstakes. It's just some guy who has been programming for a while and I guess has no clue how boolean expressions work. It's started on C# by the way. Original code
x => if (SomeBoolMeth(x) == true) return true; return false ;
If you were a professor and find this in some test, not from a basic course, what would you do?? Again: Great point!!
-
I found this code somewhere:
...
if (x == true)
return true ;
else
return false ;Actual code was the body of a C# 3 lambda expression. Anyway, horrible.
what if x was a nullable boolean ?
static bool getX(Nullable x) { if(x==true) { return true; } else { return false; } } -
what if x was a nullable boolean ?
static bool getX(Nullable x) { if(x==true) { return true; } else { return false; } }that didn't quite come out right ( first post :P ) was supposed to be a bool after the Nullable of course
static bool getX(Nullable x) -
that didn't quite come out right ( first post :P ) was supposed to be a bool after the Nullable of course
static bool getX(Nullable x)uggh, ok last attempt I am sure you follow .. ;)
Member 4364689 wrote:
static bool getX(Nullable<bool> x)
-
It IS that horrible when you join a project and the other "experienced" consultant is writing a pile of redundant crap like that: if(x == true) { control.Enabled = true; } else { control.Enabled = false; } The above adds an extra comparison operation in addition to being ugly. Besides, as someone already mentioned, How will the juniors ever progress? Forgiveable for the OP though :) The project i joined has a metric buttload of that garbage. Even worse is these guys "architected" classes without methods (can you say pre-OOP structures boys & girls?) and then created a function library (which they called a "fascade" and is NOTHING like the fascade design pattern) where you pass in an instance of this methodless "class" to the method of a fascade class to do work on it (i.e. persist it). The reasoning? They thought adding methods to the class would make it too slow. It has been a rollercoaster of emoticons. :omg: :wtf: :mad: :sigh: :(( :rolleyes: e.g. class Person { public string FirstName; public string LastName; } class PersonFascade { public void InsertPerson(Person p) { /* do stuff */ } public void UpdatePerson(Person p) { /* do stuff */ } public void DeletePerson(Person p) { /* do stuff */ } }
codemunch wrote:
class Person { public string FirstName; public string LastName; } class PersonFascade { public void InsertPerson(Person p) { /* do stuff */ } public void UpdatePerson(Person p) { /* do stuff */ } public void DeletePerson(Person p) { /* do stuff */ } }
Isn't your example standard practice? Person = Business Object PersonFacade = Database Wrapper You get exactly the same when you generate any DB Mapping using an ORM system, and i see nothing wrong with it. I always operate on the aim to separate data structure from functionality. That said, the naming conventions are misleading.
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
It's not THAT horrible. Yes, it's not exactly elegant, but sometimes this is done to make things clearer to other coders (especially less-experienced ones).
Either you've understood that "(x < 5)" is a boolean expression every bit as much as the boolean constants "true" and "false", or you haven't. There's nothing in between. The code makes it look as if the condition is somehow not a boolean expression, and therefore highlights the author's lack of understanding, of something quite fundamental, and therefore deserves to be on display as a coding horror, in my opinion. For some reason I see this done a lot with ternaries in C#: return (s == "toto"? true : false); Unfortunately proper use is less commonly seen, such as return (row != null? (int)row["count"] : -1);
-
uggh, ok last attempt I am sure you follow .. ;)
Member 4364689 wrote:
static bool getX(Nullable<bool> x)
It still makes no difference. An if condition is a boolean expression and can only evaluate to true or false, regardless of whether the equals operator is working with operands that are structures (such as Nullable) or objects (such as the object == true mentioned above) or anything else. It is of course true that the expression "x" cannot in general be known to be equivalent to "x == true", but you can ALWAYS rewrite if (x == true) return true; else return false; to just return (x == true); And of course, if x is in fact a bool, it would be clearer to simply return x.
-
codemunch wrote:
class Person { public string FirstName; public string LastName; } class PersonFascade { public void InsertPerson(Person p) { /* do stuff */ } public void UpdatePerson(Person p) { /* do stuff */ } public void DeletePerson(Person p) { /* do stuff */ } }
Isn't your example standard practice? Person = Business Object PersonFacade = Database Wrapper You get exactly the same when you generate any DB Mapping using an ORM system, and i see nothing wrong with it. I always operate on the aim to separate data structure from functionality. That said, the naming conventions are misleading.
------------------------------- Carrier Bags - 21st Century Tumbleweed.
Well, the example wasn't too detailed but as-is it took OOP and bastardized it into a function library (PersonFacade) + simple data structures (Person). You do want your persistance layer (data) to be separate but working at the business layer (often from a different class) and calling data layer specific persistance methods is ugly not to mention a pain in the ass to manage. A much cleaner solution is to have a Save() method (and depending on your scheme, a Delete()method) which then passes itself to a data layer so in your business & UI logic you don't need to call data layer specific methods residing in a completely different class. The business object takes care of itself and your code is better organized. The data layer could look like the "facade" thing or could be a smarter all-encompasing gate keeper.
-
The senior programmer could place comments like this:
if (x == true) return true; else return false; // the previous snippet could be replaced with // return x; // but i have chosen not to use this so that junior-programmers // can understand how two different values can be returned by one single function // // To other senior programmers. Please leave the previous snippet or replace it by // another snippet that would clarify the problem even bettercodito ergo sum
or he could just save the time it takes to write that long, verbose comment and just write return x;
-
or he could just save the time it takes to write that long, verbose comment and just write return x;
-
Then it should be
return x ;
// If I ever catch any of you writing it as
//
// if (x == true)
// return true;
// else
// return false;
//
// I'll have you tied to an anthill and covered in honey!PIEBALDconsult wrote:
I'll have you tied to an anthill and covered in honey!
Cute. This should get a Vote of '5'.
Vasudevan Deepak Kumar Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson -
No time or effort should be spared in the process of education of the younger generation. Even better would be.
return (x == true) ? true : false;;P
codito ergo sum
With longer conditions and expressions, ternary operator becomes tedious to debug. X|
Vasudevan Deepak Kumar Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson -
I found this code somewhere:
...
if (x == true)
return true ;
else
return false ;Actual code was the body of a C# 3 lambda expression. Anyway, horrible.
:eek: So much for just doing a
return x==true;If x is a bool, then just a simple return of x will work :-\"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
-
I found this code somewhere:
...
if (x == true)
return true ;
else
return false ;Actual code was the body of a C# 3 lambda expression. Anyway, horrible.
I considered creating a new thread for this, but (obviously) decided not to. I spent yesterday at the "Heroes happen {here}" event (in Phoenix) and most of the demoes in the "developers' track" was presented by a "developer evangelist", and it seemed like every one of his methods that returned a
boolwas written in that form. :mad: