|
Florin Jurcovici wrote: Although I don't buy either (no ternaries and braces around single statements) - you write the code as is fit initially, and reformat/refactor as needed when you change it.
Yes, exactly. And a simple
return statement ? a : b
... is not too hard to read, for sure.
Someone here is really passive-aggressive anti-ternary, judging by the downvote my other post got 
Heh, that pattern is even worse.
|
|
|
|
|
Probably gets paid by lines of code.
|
|
|
|
|
BobJanova wrote: Someone here is really passive-aggressive anti-ternary, judging by the downvote
my other post got
Some people hate concision. Many of them, IMO, will need to look that word up :P
Truly, I've seen some real abuse of ternaries, which becomes a real horror if you have to add "elseif" cases. This is why some organizations ban them completely.
|
|
|
|
|
BobJanova wrote: Interesting to see someone else who likes to do
if(0 != ...)
... as well.
This is called Yoda condition.
|
|
|
|
|
VUnreal wrote:
BobJanova wrote: Interesting to see someone else who likes
to do
<SPAN class=code-keyword>if</SPAN>(<SPAN class=code-digit>0</SPAN> != ...) ...
as well.
This is called Yoda condition.
LMAO, I first saw this suggestion somewhere around 1991, and Yoda had nothing to do with it (it might have been Michael Abrash or Kent Porter, or some one-shot contributor to Dr. Dobbs, which had just stopped doing Software Orthodontia and Calisthenics a couple of years before).
|
|
|
|
|
Personally, I'm not a fan of ...
if (0 != ...)
I understand the arguments, that its less likely to cause an error if you use = rather than ==, but seriously, that doesn't occur that often (at least with reasonably competent developers), and I prefer readability to obscurity.
I've never seen a mathematical formula with the constant term on the l.h.s.
|
|
|
|
|
Rob Grainger wrote: I understand the arguments, that its less likely to cause an error if you use =
rather than ==, but seriously, that doesn't occur that often (at least with
reasonably competent developers), and I prefer readability to
obscurity.
Uh, huh....try bouncing back and forth several times a day between Pascal and C (then) or C# and VB.NET (now) and see how "competent" you stay, good buddy (BTW, that code-reading problem you have can be solved with practice...and this isn't mathematics). At the time this technique was suggested, it was one of the most common errors in C/C++ programming, and it's still a common error in all C's descendants when the coder spent signficant school or work time working in just about any other classical imperative language framework as most of them used a single equal sign as the operator for logical equivalence. Ah, the light just went on! You haven't spent much if any time outside the C box. You should get out more.
|
|
|
|
|
"You haven't spent much if any time outside the C box"
VB, Smalltalk, Eiffel, Haskell, LISP, to name a few. But evidentally, while I can manage to read both and learn to switch, you seem to be incapable. Every day I switch between VB, C#, and C++ which have similar differences.
"just about any other classical imperative language framework"
You may not have got out much recently, but the vast majority of languages in use nowadays have adopted these conventions.
|
|
|
|
|
Rob Grainger wrote: VB, Smalltalk, Eiffel, Haskell, LISP, to name a few.
Is this for product, or for your own research? under what time constraints for production delivery?
Rob Grainger wrote: Every day I switch between VB, C#, and C++ which have similar differences.
Just those? oh happy day. And how many separate projects are you working on simultaneously? How often do you have to drop one at your manager's demand to make a change in another for QA within the hour? If you are juggling four or five projects with at least four of them modifications to existing items and two of them were given to you yesterday for delivery the day before that, AND you still never, ever type a single equal sign where you meant a double equal sign...you're still too snotty to be let near most production programmers in corporate environments. No one who thinks they're perfect belongs near a production system, IMO - I've seen that sort of arrogance in action, and failed releases and recalls are just the biggest scratches in that surface. It's not the things you don't know that get you, it's the things you think you know that just aren't so, like the myth of your own continuing perfection. Good luck with that, btw
|
|
|
|
|
Sorry, I wasn't claiming perfection, I just stated that my errors rarely include the one under consideration - and when it does occur a handy compiler warning alerts me - if there really is an error, I correct it.
Generally, I rarely perform an assignment within the middle of an expression - again, they're too easy to misread. My point was really that I prefer readability of source code - so that myself an other developer's don't have to perform a little mental rearrangement every time I read the code.
To answer your question, I've used all of those except Haskell and LISP in production environments. LISP I haven't come across in those circumstances, Haskell I'm still learning. I was lucky enough to use Smalltalk a few years ago on a few projects - that was a real education.
I'm sorry that descended into such a bitterness, but I felt the tone of your initial reply a bit defensive - in both cases its just a preference, unless we end up working on the same project, there's no need for it to bother either of us. I was just stating my preference, feel free to keep yours.
|
|
|
|
|
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).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
