|
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! ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
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)
|
|
|
|
|
You're not alone on that one. I think that many developers have that issue.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Some of us have attention spans longer than a Twitter message 
|
|
|
|
|
Thank you. This was exactly the point I was trying to make.
|
|
|
|
|
|
Good, every one saying about the readability and Debugging,
However this is a Small code, which is called by many classes.
my point is why should i declare a extra variable "resultflag", where this method called 5000+ times in every 10 seconds.
modified 17-Jan-12 7:53am.
|
|
|
|
|
I shouldn't worry about it, if you're accessing a data layer any saving from avoiding allocating 32-bits on the stack is negligible.
Premature optimisation is the root of all evil.
The only actual "improvement" you've made is that the code occupies less space on screen. All the "improvements" you claim will be performed by a decent optimising compiler on release code anyway.
Design for readability/maintainability, then optimise as you have evidence it is worthwhile.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
I disagree with the point the OP is trying to make. The original code is easier to read
and 
.
and commas, it takes longer to read and understand when you're not familiar with the code, and it's harder to spot a factual error. 
,
but in a professional environment,
and your compiler is not awesome, 
like in some embedded systems, or some video games. 