A big if
-
KarstenK wrote:
It looks very strange or like C#.
What's your matter with C#? It allows for (and encourages) the cleanest and well structured code ever. :confused: Regards Thomas
-
But it allows -as seens- also the opposite. Strange is in the above code alway one Set-Function for User and Password. I hope the Ftp-objects isnt a C# class. X|
Greetings from Germany
KarstenK wrote:
But it allows -as seens- also the opposite.
Sure, it allows for bad coding style as well - as every other programming language does even more. Do you really blame C# for being a language that does not impose on its user what to say with it?? Do you have a car that forces you to adhere to traffic rules? Does your money tell you what to buy with it? ... :wtf: Regards Thomas
-
Let's assume it's C++. I consider sth. like the code above generally bad coding style. There is far to much nesting here. Supposed that most of the programmers (at least the ones I know, including myself) make an indentation of four spaces (not only two as in the 'sample'), you would quickly run out of monitor space... I would suggest a kind of 'waterfall style' coding here:
if ((nErrorCode = cFtpConn.SetHost(HOST)) != 0)
{
Log(...);
return;
}if ((nErrorCode = ...
{
Log(...);
return;
}...
This is also not perfect since it introduces many returns, but it improves the readability of the code and the return conditions are trivial and repetitive.
PIEBALDconsult wrote:
If it's C#, the methods should probably throw Exceptions.
Agreed. In a perfect world, C# - Methods would always throw exceptions and never signal an error by means of a return value. (As long as this is affordable in terms of performance). Regards Thomas
modified on Monday, November 3, 2008 4:55 AM
This is also not perfect since it introduces many returns, but it improves the readability of the code and the return conditions are trivial and repetitive.
How about:
if ((err = action1()) != 0)
log_error1();
else if ((err = action2()) != 0)
log_error2();
else if ((err = action3()) != 0)
log_error3();or
do
{
if ((err = action1()) != 0)
{log_error1(); break;}
if ((err = action2()) != 0)
{log_error2(); break;}
prepare_for_action3();
if ((err = action3()) != 0)
{log_error3(); break;}
...
} while(0); /* Loop used to allow break */The former style is nicer if each action is a single function. If stuff is required between the actions, the second approach may be helpful.
-
This is also not perfect since it introduces many returns, but it improves the readability of the code and the return conditions are trivial and repetitive.
How about:
if ((err = action1()) != 0)
log_error1();
else if ((err = action2()) != 0)
log_error2();
else if ((err = action3()) != 0)
log_error3();or
do
{
if ((err = action1()) != 0)
{log_error1(); break;}
if ((err = action2()) != 0)
{log_error2(); break;}
prepare_for_action3();
if ((err = action3()) != 0)
{log_error3(); break;}
...
} while(0); /* Loop used to allow break */The former style is nicer if each action is a single function. If stuff is required between the actions, the second approach may be helpful.
Hmm, I fear I'm not very happy with that either. The first example is just not working because due to
elsethe branches below the first one are simply unreachable, no matter what the outcome ofaction1()may be. The second alternative is just replacingreturn;withbreak;. Furthermore, it introduces a hardcoded boolean expression which always evaluates to the same value. This in my opinion is not very desirable in itself. Sure, in the example things are very easy to understand, but imagine a real life example where things can become much more complicated... Regards Thomas_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
-
Hmm, I fear I'm not very happy with that either. The first example is just not working because due to
elsethe branches below the first one are simply unreachable, no matter what the outcome ofaction1()may be. The second alternative is just replacingreturn;withbreak;. Furthermore, it introduces a hardcoded boolean expression which always evaluates to the same value. This in my opinion is not very desirable in itself. Sure, in the example things are very easy to understand, but imagine a real life example where things can become much more complicated... Regards Thomas_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
Thomas Weller wrote:
The first example is just not working
Sorry for that - of course it is working. :doh: My brain must be on vacation or something. Thus this indeed is a viable alternative. Regards Thomas
_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
-
Hmm, I fear I'm not very happy with that either. The first example is just not working because due to
elsethe branches below the first one are simply unreachable, no matter what the outcome ofaction1()may be. The second alternative is just replacingreturn;withbreak;. Furthermore, it introduces a hardcoded boolean expression which always evaluates to the same value. This in my opinion is not very desirable in itself. Sure, in the example things are very easy to understand, but imagine a real life example where things can become much more complicated... Regards Thomas_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
Thomas Weller wrote:
The second alternative is just replacing return; with break;. Furthermore, it introduces a hardcoded boolean expression which always evaluates to the same value. This in my opinion is not very desirable in itself.
Replacing a return with a break may be useful if the code has to do something besides totally exit a function. If the routine opened a file at the beginning, for example, I would consider doing a break and then closing the file after the 'while' to be much cleaner than doing "close(theFile); return;" in each failure case. It's a little irksome having a hard-coded boolean constant like that, but C does not provide any other block structure whose semantics are "run once, but be able to jump to the beginning or end." I would consider "do ... while(0);" and "do ... while(1);" to be cleaner than a "goto", at least in cases where the enclosing block does not contain any case labels. If a certain amount of code will be common to several case handlers, it would be far better to do something like:
switch(foo)
{
case 0:
code_0_special();
COMMON:
common_to_code_0_1_3();
break;
case 1:
code_1_special();
goto COMMON;
case 2:
code_2_special();
break;
case 3:
code_3_special();
goto COMMON;
default:
handle_default();
}than
switch(foo)
{
case 0:
code_0_special();
do {
common_to_code_0_1_3();
break;
case 1:
code_1_special();
continue;
case 2:
code_2_special();
break;
case 3:
code_3_special();
continue;
default:
handle_default();
break;
} while(1);
}or
switch(foo)
{
do
{
case 0:
code_0_special();
break;
case 1:
code_1_special();
break;
case 3:
code_3_special();
break;
} while(0);
common_to_code_0_1_3();
break;
case 2:
code_2_special();
break;
default:
handle_default();
break;
} while(1);
}The former would IMHO be an appropriate use of "goto"; the second is just plain horrible. The third isn't quite so bad, but is IMHO less clear than the goto.
-
I used to have a co-worker who did almost the same It went a bit along the lines off this: (sorry for the vb code but well I code in it :) )
Dim rc as integer=0
rc = doSomething()
if rc <> 0 then goto Errormessage 'yeah a gotorc= = dosomethingelse()
if rc <> 0 then goto Errormessage
... ' went on and on like this for about 200 lines
Errormessage:
Select case rc
case 1
messagebox.show("...")
case 2
messagebox.show("...")
...
end selectI true nightmare to debug but it wasn't even the worst thing I saw in his code. O and I should mention that we had/have a specific way to handle errors and the messages that should go with them. Needless to say this isn't that way :) , he just choose to ignore everything we(manly my boss (and his)) told him and just do his own thing, he didn't last very long. If I have the time I'll post some of the horrors I'v seen in it
I don't see the problem here (I assume this is VB 6?). It's a linear sequential pattern. If you think about it it's semantically equivalent to a try-catch block.
Kevin
-
If the exceptions are forbidden for whatever reason, there is nothing wrong with it.
I agree. I generally prefer to see the normal paths first followed by the error paths. Deep nesting should be avoided other things being equal. But if there is a regular pattern to the code (as in your COM example elsewhere in the thread) this is fine. What is not fine is when you have deep nesting combined with loops and randomly sprinkled if-then-else blocks.
Kevin
-
I don't see the problem here (I assume this is VB 6?). It's a linear sequential pattern. If you think about it it's semantically equivalent to a try-catch block.
Kevin
If it was VB6 is would agree but this code was written in .NET and only about a year ago (with visual studio 2005)
-
If it was VB6 is would agree but this code was written in .NET and only about a year ago (with visual studio 2005)
OK, in that case he should be shot. :laugh: BTW, why did they keep that stuff in VB .NET? Ditto Option Explicit turned off by default?
Kevin
-
OK, in that case he should be shot. :laugh: BTW, why did they keep that stuff in VB .NET? Ditto Option Explicit turned off by default?
Kevin
Yeah and that wasn't even his biggest horror :sigh: I'd laugh if I didn't have to work in the code :sigh:
-
If it was VB6 is would agree but this code was written in .NET and only about a year ago (with visual studio 2005)
This code was written by someone who is used to VB6, I bet. In this case it's not the code that is awesome - it's the language... :) Regards Thomas
_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
-
I agree. I generally prefer to see the normal paths first followed by the error paths. Deep nesting should be avoided other things being equal. But if there is a regular pattern to the code (as in your COM example elsewhere in the thread) this is fine. What is not fine is when you have deep nesting combined with loops and randomly sprinkled if-then-else blocks.
Kevin
Kevin McFarlane wrote:
deep nesting combined with loops and randomly sprinkled if-then-else blocks.
They also call it reality - at least very often... :((
_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
-
This code was written by someone who is used to VB6, I bet. In this case it's not the code that is awesome - it's the language... :) Regards Thomas
_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
Actually his resume said he had 20+ years of freelance programming experiance and 5 off those in C#.NET (if that is true is another story). He also traded in a 3000€+ a month job for a 2000€ a month job :confused:
-
Kevin McFarlane wrote:
deep nesting combined with loops and randomly sprinkled if-then-else blocks.
They also call it reality - at least very often... :((
_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
:laugh:
Kevin
-
Actually his resume said he had 20+ years of freelance programming experiance and 5 off those in C#.NET (if that is true is another story). He also traded in a 3000€+ a month job for a 2000€ a month job :confused:
Tom deketelaere wrote:
Actually his resume said he had 20+ years of freelance programming experiance and 5 off those in C#.NET
Impossible. This is an old school VB programmer. You can clearly see this from the above snippet (I'm not saying it's somehow bad VB6 code, but that it for sure is VB6 code). There must be sth. wrong here... :confused: Regards Thomas
_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
-
Tom deketelaere wrote:
Actually his resume said he had 20+ years of freelance programming experiance and 5 off those in C#.NET
Impossible. This is an old school VB programmer. You can clearly see this from the above snippet (I'm not saying it's somehow bad VB6 code, but that it for sure is VB6 code). There must be sth. wrong here... :confused: Regards Thomas
_Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software._
Well I can imagine that at some point he did work with vb6 (hell even I did) but this was written in .NET. And his resume did say 5 years experiance in C#.NET but we (my boss and I) do think he had been lying a bit, since after he was fired here he told one off our customers (where he was being interviewed for a hardware maintenance position) he had experiance in maintaining servers. He could barly keep his desktop pc running while he was here so... (he was actually not allowed to come anywhere near our servers :-P ) The guy had the tendancy to overcomplicated things (currently working on another one off his programs to get the CPU usage and Ram usage down since it olmost takes 100% CPU and more than 100mb ram, for a programme without GUI that's alot)
-
KarstenK wrote:
But it allows -as seens- also the opposite.
Sure, it allows for bad coding style as well - as every other programming language does even more. Do you really blame C# for being a language that does not impose on its user what to say with it?? Do you have a car that forces you to adhere to traffic rules? Does your money tell you what to buy with it? ... :wtf: Regards Thomas
Right - and think about the possibilties of "bad coding" e.g. in C++ (add some mystic macros - done) vs. C#.. I think C# is a lot cleaner and full of nice features. The best programming language I know... (I used one or two during my career... :) )
-
Recently, I stumbled across this little gem. I don't have the exact code handy, but the gist of it is:
nErrorCode = cFtpConn.SetHost(HOST);
if (nErrorCode == 0)
{
nErrorCode = cFtpConn.SetUser(USERNAME);if (nErrorCode == 0)
{
nErrorCode = cFtpConn.SetPassword(PASSWORD);if (nErrorCode == 0) { nErrorCode = cFtpConn.SetPath(PATH); if (nErrorCode == 0) { nErrorCode = cFtpConn.SetFilename(FILENAME); if (nErrorCode == 0) { // Retrieve files, adding a few _more_ levels of `if` } else { Log("Error setting filename"); } } else { Log("Error setting path"); } } else { Log("Error setting password"); }}
else
{
Log("Error setting username");
}
}
else
{
Log("Error setting host");
}