|
Can't you do if condition then one-statement else other-statement though if you don't need a block?
|
|
|
|
|
Yes, but I've always hated doing those, unless you write it on a single line:
if condition then DoSomething() else DoOtherThing(); That's the only way in my mind to avoid stupid mistakes like this:
if condition then
DoThing1();
DoThing2();
DoThing3();
MainStuff();DoThing2() and DoThing3() look like they're part of the if, but they're not. I do the same thing in C-style languages. If an if-statement occupies more than one line, it gets braced.
Software Zen: delete this;
|
|
|
|
|
I agree and would always put that on a single line.
|
|
|
|
|
Quote: If an if-statement occupies more than one line, it gets braced.
Maybe I'm naïve, but I thought everybody did that! 
|
|
|
|
|
I've worked with people who did this:
if condition
DoSomething();
else
{
DoOtherThing1();
DoOtherThing2();
}or
if condition
{
DoSomething1();
DoSomething2();
}
else
DoOtherThing();Both of which give me the creeping heebie-jeebies.
Software Zen: delete this;
|
|
|
|
|
oh, urm, oops?
I do that...
|
|
|
|
|
It's valid syntax, and if you're confident that you'll never ever forget to add or remove braces appropriately, go for it.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: if condition then
DoThing1();
DoThing2();
DoThing3();
MainStuff();
Yeah that's one of my all-time favorites. It usually starts out like:
if(condition)
DoThing1();
And then someone comes along later and adds DoThing2(), and the compiler silently chuckles to itself and lets the code do a lot of Thing2.
Personally, I like to always use curly braces to block off code for that very reason, even if it's only one statement. If I see something like that with one statement, I'll add the braces so it's clear when someone comes along and changes it.
Putting it all on one line works fine as well, but I like to always create a code block because it makes it easier to add statements later. And really, what's the point of keeping it on one line? But I know a lot of programmers have an irrational fear of vertical space
|
|
|
|
|
Oh no, you misunderstood the guy who wrote that piece of code.
Never did he intend that DoSomeThing() is executed only when some codition is true. He just wanted to make his colleagues (who'll have to maintain his buggy code after he quit his job) believe so.
|
|
|
|
|
Seems like a new style of comment... if you're compiler doesn't support any comments. 
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
I had to read it three times before spotting the problem. Go bugged by the fact that DoSomeThing didn't have parenthesis.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Me too. I didn't see the semicolon until I review it two or three times. So maybe it is not a trap but a genuine bug. Some times you check your code 10 times and do not see this kind of bugs. 
You may forget having good days, just because you are remembering the past or thinking too much about the future. Live now and enjoy the moment!!
|
|
|
|
|
Tell me about it. I'm specially vulnerable to problems that are right in front of my face.
I do this too often: 
Maybe it's my short span of attention.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
This errors can be present in C like language. The last only in C#
This one is usual (very)
if(Something)
One();
two();
...
Of course only One() is inside the if(), but it seems that the other two instructions are inside also. I did fall in this bug many times until I decided to enclose into curly braces any if() or loop with one or more instructions. It could increase the number of lines, but, for sure, decrease the bugs.
Other one:
bool MyBoolValue = true;
if(MyBoolValue = false){
... SomeStuff ...
}
Maybe the compiler throws a warning, but this statement is valid. Surely is not what you want to do because you have omitted one equal sign:
if(MyBoolValue == false)...
I have no solution to this one, but to check again 
Of course the comparison is not necessary, because MyBoolValue is true or false per se. 
if(MyBoolValue)...
for(int i = 0; i < MyArray.GetUpperBound(0); i++){
SomeStuff....
}
You must remember that GetUpperBound(0) does not start in '0' but in '1', because is the number of elements not the dimensions of the array so it must be:
for(int i = 0; i <= MyArray.GetUpperBound(0); i++)
I will try to remember more "Mistakes" that are common for me, but for sure here are more qualified people to show you many more.
You may forget having good days, just because you are remembering the past or thinking too much about the future. Live now and enjoy the moment!!
|
|
|
|
|
I usually prefer:
if (42 == ComputeSomeThing(x)) {
}
This one avoids the = against == pit.
Another thing I do: my IDE is configured to show operators (like '(){};,+-=...') in color, so they are a bit harder to miss (like the original example).
There are two other tools that can help with this: compiler warnings, and static code analysis.
JM2B,
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: This one avoids the = against == pit.
LOL, that one kills me, because I'm constantly switching back and forth between C# and VB 
|
|
|
|
|
gervacleto wrote: if(Something)
One();
two();
...
This can also happen in C#, but auto indent of Visual Studio makes you less likely to fall in this trap.
gervacleto wrote: if(MyBoolValue = false){
This happened to me several times and the warning saved. I always pay attention to warnings.
gervacleto wrote: if(MyBoolValue)
I do not consider this a bug, it is actualy a coding style. I do it myself.
gervacleto wrote: for(int i = 0; i <= MyArray.GetUpperBound(0); i++)
Never used this construct, so I wouldn't know. But will keep my mind to it in case I run into this. Thanks!
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
the semi-colon on the end of the conditional, the block will always execute.
DoSomething is in its own little world and will always execute.
C# will just raise a warning on the conditional but will not compile with the DoSomeThing becuse it is not a method or an assignment.
But, what if it is not C# compiler, then there could be compilers that would allow this and it would be worthless code, i still use Crimson, NotePad, etc to write code. Either to many semi colons or not enough !!
|
|
|
|
|
I bet that in DoSomeThing there is logic to handle the strange case when the if condition is not firing properly. 
|
|
|
|
|
Ooh, nasty! Couldn't see it at first.
Check out my latest article: Celerity: How it was all done.
A complete how-to on our sensor-driven head-tracking virtual reality tunnel game in C#.
|
|
|
|
|
Delphi4ever wrote: if(SomeThing == SomeOtherThing);
I remember years ago spending a few hours debugging why (in C++):
for (int i=0; i<10; i++);
DoSomething();
where DoSomething executed only once.
I only had to learn that lesson once!
Marc
|
|
|
|
|
There may be trouble ahead!
There's a constant debate at our place about the use of third party libraries. Half our lot refuse to use them, preferring to write absolutely everything themselves.
It's no coincidence that the developers who use third party stuff get their tasks done quicker and with less bugs opened from said tasks. I'd call this good productivity.
The current Not Invented Here debate is based around expression parsing. We want to be able to interpret expressions defined in Xml files in place of static attribute values, DateTime.Now.ToString("format of some sort") is a great example of what we need to be able to do.
Earlier in the week I introduced Flee - Fast Lightweight Expression Evaluator[^] to members of the team, upon which reasons were being invented not to use it.
Autonomously I've knocked up a working example that covers all the requirements we've specified in about an hour using Flee. Our planning indicates that we've put aside 5 days for writing an expression engine from scratch. Now I can guarantee that in 5 days I'd be able to write something that can evaluate simple static property and method calls, but very little else. In 1/40th of the time using a third party library I've done the job as far as I'm concerned and we've got a component that can do a hell of a lot more to boot. Not only that, but it's been peer reviewed on CodePlex and on here with almost entirely 5 star ratings and nearly 15,000 downloads on CodePlex. It's LGPL licensed and as we're not modifying it and it's already freely available, we won't have a problem redistributing it.
If they're not watertight reasons for using a third party component instead of rolling your own then I don't know what are.
Now I'm totally biased when it comes to how I develop. I 'll use any third party library that I feel can help me get my job done quicker so I can concentrate on quality and I absolutely detest reinventing the wheel, which makes it very difficult for me to see peoples' points of view when they object and claim writing everything from scratch is somehow better.
What objections do you have to using third party stuff?
|
|
|
|
|
My issue with libraries is that they often do something that's nearly but not quite what you want, and you end up changing what you want to fit the library, which is backwards. This is particularly true with more complex frameworks like Hibernate, Spring etc. A good example from my personal experience is lambdaj[^], a fluent query library in Java. It looks great, until you realise that it uses dynamic proxies so you can't use it on a list of strings, it loads everything into memory so you can't use it on external data sets, and to work around those two things is more effort than writing the subset of query functionality that you need.
On a project level, it also means that anyone new to the team has to learn a new library, whereas presumably they are familiar with the standard library (java.*, System.* etc) which a home-rolled version will use.
If it really, actually, does do the thing that you want, then fair enough. But it's surprising how often you find that a little way down the road you have nasty wrinkles in your code where it butts up against the library, because that third party tool doesn't actually do things the way you want to do them.
|
|
|
|
|
I understand what you're getting at. I've also come across libraries that haven't quite done what I was after. In that case you're completely correct.
Obviously I'll evaluate a library first. It's not as if I download the first thing I find and plump for that like it's cool. It also has to have good documentation and positive peer reviews because without them you're on your own, with someone else's code.
You can't guarantee that it will be any easier picking up someone's homebrewed alternative. You'd still have to learn that and it might not have the same documentation or review coverage as the third party component. This is where I find independent peer reviews are worth their weight in gold.
At any rate, I've still got 39 of the 40 estimated hours left for ironing out my wrinkles.
|
|
|
|
|
totally agree.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
