|
I am also sorry for the descent of tone. Personally, I'm embarrassed as hell every time I commit that particular error, and I happened to be a regular Dr Dobb's reader at the very time someone in Dr Dobb's suggested moving any constant value to the left side of the equivalence operator to avoid at least some of these instances (1989, I believe). The business environment and our over-ambitious enterpreneur-president put us into Death March mode on a monthly basis (seemingly) by promising his clients delivery before we'd established we could write it, so 36- and 48-hour days occurred several times a year and 24-hour days were a common occurrence. Under those conditions, around the 22nd hour spelling your own name correctly can be an issue - thus, any technique that could help avoid any simply stupid error could help keep us from having a recall.
Note I never claimed that sane development conditions led to these errors
And again, sorry for the tone. I still have bad memories of a technical writer who could have been a stupendous programmer if he hadn't lied his way to a position way beyond his experience because he believed that teaching himself how to program in VB, he'd be able to duplicate and surpass the performance of any data access methods we'd written in the previous two years; by the end, two major data fixes and three failed releases later, he was pulled by his consulting company and put back to writing documentation, and he was visibly broken by the process. When, at the beginning, I'd tried to show him what we'd already done and why (two years development of a near-perfect cache load), he ignored me; when I called him on it in a meeting, my boss favored him (boss was new, he'd hired the company who'd provided this guy, etc.) and thus we sailed to near doom before upper management finally intervened.
As a result, nothing scares me worse than a developer who thinks he (1) knows everything and (2) does everything perfectly every time. Please pardon me if I mistook you for one of these, and please pardon me if I went "over the top."
|
|
|
|
|
Hey, no harm done. I'm left feeling much better from the whole encounter now.
I know the feeling re. terrible project decisions, I'm having to live with some at the moment, and it can grind you down.
|
|
|
|
|
Rob Grainger wrote: Hey, no harm done. I'm left feeling much better from the whole encounter
now.
As am I.
Rob Grainger wrote: I know the feeling re. terrible project decisions, I'm having to live with some
at the moment, and it can grind you down.
Yes, it can. Luckily, our heads are made of stuff too hard to grind to meal, isn't it?
|
|
|
|
|
There is a valid reason for using the ResultFlag form. It's called debugging. How do you find out what went wrong when the ExecuteNonQuery returns nonzero? Don't you think the value returned might give you a clue?
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Agreed with Peter,
Beside this just reduce the code, but I dont see any performance improvement. also in some programming language comparison does not return only true and false but sometime it also return -1(VBA)
|
|
|
|
|
Nope, not right. Any decent debugger/IDE has a facility for evaluating expressions (IIRC VBA has one too - something called the immediate window, I think). Depending on the language, your compiler might not optimize away the additional variable which you use. Besides, more compact code is always a bonus. And even in VBA, for this particular case, what you care about is != 0, which even VBA evaluates correctly, since -1 and 1 are both true, only 0 being false.
|
|
|
|
|
A debugger does not perform function calls in expressions - it mustn't, function calls can have side effects.
"more compact code is always a bonus": this is a questionable statement.
|
|
|
|
|
If examining the result while debugging is your main concern, you can still write
int ResultFlag = MSSqlHelper.SqlHelper.ExecuteNonQuery(SqlServerConnection.Cn, CommandType.Text, Sqlstring);
return ResultFlag != 0;
I've seen worse though...
const bool valTrue = true;
const bool valFalse = false;
bool doTheWork()
{
...more impressive code...
if ( result == valTrue ) return true;
else return false;
}
That coder was preparing himself for the time that valTrue became false or something!?
|
|
|
|
|
I see that all the time. You have to change doTheWork to workData though
|
|
|
|
|
Wow, that is bad. They don't even use an abstract factory pattern to generate valTrue and valFalse. What happens if you want to change how valTrue and valFalse change later on, but without changing the DLL!?
|
|
|
|
|
In VBA, -1 is True (check out the bit values sometime).
|
|
|
|
|
Agree.
There is another VERY important reason why you should NOT change working production code unless you really must; Don't change tried and tested code!
Ok. this code sample you show us is a bit clumsy but it works, right? So why change it? IMHO a good programmer must learnt NOT to change production code unless it's really really needed.
|
|
|
|
|
I definitely disagree with you there. Cleaning up code results in a (marginally, for any particular instance, but it builds up) nicer codebase to work in and that results in better productivity for everyone on the team. If it's 'tried and tested' then you can check that the tests still pass and therefore be sure you haven't broken anything with your cleanup.
|
|
|
|
|
I agree - Cleaning up the codebase is very tempting, it's much nicer to work on "clean" code. But my point is this: Cleaning up production code just for the sake of making it look "nice" is very dangerous because (depending on code size of course) you WILL create new bugs in doing so.
|
|
|
|
|
You won't if the code is properly tested, or if you can demonstrate equivalence for all inputs (often not as hard as it sounds).
|
|
|
|
|
Snorri wrote: But my point is this: Cleaning up production code just for the sake of making it look "nice" is very dangerous because you SOMETIMES will create new bugs in doing so.
FTFY.
And sometimes cleaning up code will fix latent bugs that no one has run into yet, or possibly they've hit them and just haven't reported them, or possibly they've hit them and thought that was normal behavior.
Creating new bugs will be mitigated with unit tests; which of course one always has before refactoring.
|
|
|
|
|
|
Don't get upset. FTFY is a common short hand here, it means "Fixed That For You".
Whenever a quote is followed by FTFY, the quoter has intentionally changed the text. There are a myriad of reasons for this. Often it is done for humorous effect or, as in this case, to show that the quoter almost agrees with the OP except for a minor difference.
[edit]
As a member for eight years, I'd assume you would know this.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Nagy Vilmos wrote: As a member for eight years, I'd presume you would know this.
FTFY
And from the clouds a mighty voice spoke: "Smile and be happy, for it could come worse!"
And I smiled and was happy And it came worse.
|
|
|
|
|
CDP1802 wrote: Nagy Vilmos wrote: As a member for eight years, I'd presume you would know this be sober by now.
FTFY
ftftfyfy
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
LMAO...I've been here a member for only seven years, so now I know a secret from you eight-year-olds....I'm growing up! Serioiusly, I've never been able to figure the meaning of FTFY in context, and it didn't seem to be adding that much meaning in any case except as a pejorative, so I never bothered asking anyone.
|
|
|
|
|
Sorry, sorry. Mea maxima culpa.
(and LOL)
|
|
|
|
|
I think I have to support your statements downvoted by others - you seem to stand allone with your opinion - Not any longer! @All the theorists with the "well tested code"... I learned the lesson not to change production code "on the fly". Because sometime a piece of code looks stupid or ugly - but it's just an undocumented workarround for a bug in an underlaying system or whatever. It's not always good to assume all other programmers are idiots... So if I change (or better "refactor") production code - this is my intention - it's like adding a new feature, and yes if there are unit tests in place, it helps. But @all the "perfect code" guys: If it is a "well tested code"-project, unit tests exists - how likley is it to find a real coding horror, isn't it more likely to find it in the "not so well tested" code bases (unit tests??? - whats a "unit"?). I view myself as a "perfectionist" while coding, code style nazi, refactoring fan,... - but there is a real world out there where "perfection" most times mean: "Not complete crap" - I worked on tons of codes in my life, ranging in style and effort from "bloody beginner" to "code god" but "academic perfection" I have rarely seen in a non trivial product. Don't get me wrong - I'm always a fan of "better/shorter code" - but some commenters may have to go through some real projects (why not let's say > 1million lines of code), and learn to leave the existing code - if nobody complains about it - alone!
|
|
|
|
|
johannesnestler wrote: I view myself as a "perfectionist" while coding, code style nazi, refactoring
fan
You should apply 5 seconds of that into your authoring skills.
You really need to work on your paragraphs if you want people to actually read your posts.
|
|
|
|
|
thank you for feedback, i'll try to follow your advice in my future comments (it's a lot easier for me to structure code than normal text)
|
|
|
|