|
 
Real programmers use butterflies
|
|
|
|
|
Very true for interpreted languages!
...and who wants to waste time writing the parser for a comment when devs do not use comments anyway.
|
|
|
|
|
Confused, because I can always add the brackets if I add more lines.
|
|
|
|
|
Firstly, I'm coding in a very old language. Here's the exact line of code. Hopefully you can translate to a 'proper' language.
IF ERROR.MSG = "" THEN ERROR.MSG = "Error ":ERROR.CODE
It was a catch-all I inserted, (without being asked), to ensure that an error message would always be returned, even when it was an unknown error code. Yes, it's a single "=" for both conditions and assignments. And I was made to change it to upper-case. FFS!
What they wanted, was:
IF ERROR.MSG = "" THEN
ERROR.MSG = "Error ":ERROR.CODE
END
But, the point that I was trying to make was: not that my way is right, but: if they want it doing a particular way, it should be documented - particular as the code-base contains a, pretty much, 50:50 split of both syntaxes.
|
|
|
|
|
|
Richard MacCutchan wrote: Cobol?
 It's slightly easier than that! It's a (fairly significant) variation on Basic, which comes as part of the Universe DBMS. It's derived from Pick DataBasic (another one you won't have heard of!) and is actually very easy to develop with - albeit limited in scope. i.e. It's for dumb terminal applications. I like it though.
|
|
|
|
|
5teveH wrote: Pick DataBasic (another one you won't have heard of!)
Don't be too sure. I have been writing code on quite a few different systems (a few whose name I cannot remember) since 1966 (yes, that is really nineteen-sixty-six).
|
|
|
|
|
You do it all wrong! The correct syntax is:
if (parameter == null)
{
return;
}
else
{
}
Reason: always add an else to an if, even if it's empty, because otherwise a future nested if could accidentally add an else at the wrong nesting level! 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Take thy code to The Weird and The Wonderful[^] where it belongs! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Well, it definitely doesn't belong on an agile forum.
But it would be fun
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Nah! The correct syntax to use is:
if (parameter =
= NULL)
{
return;
}
else
{
}
|
|
|
|
|
if (null == parameter) -> even better.
|
|
|
|
|
As soon as I switch to a multi-line statement inside any conditional I put in the brackets. I've had too many bugs over the years because the brackets weren't there.
|
|
|
|
|
I'll do a single line if-statement if the code inside the braces is a single line, function call, etc. If I were reviewing another's code, either way would be suitable.
|
|
|
|
|
This is why we use a code formatter at our place, to avoid the drama and debates on the code reviews! Everyone's code looks equally terrible.
|
|
|
|
|
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
|
Agree. Similarly, we use Resharper. I just accept whatever it does and move on.
|
|
|
|
|
Quote: I stood my ground, (and won out), not because I didn't want to spend 2 minutes changing the code, but because I value properly documented standards.
Personally, I would have spent the 2 minutes changing the code (actually I wouldn't have done it that way but that's a different argument) ..
.. AND a further 2 minutes updating the standards (or at least 2 minutes making life h3ll for the owner of those standards until they updated them  )
|
|
|
|
|
Since both formats are used within the code base the person who bounced it was just wrong. Code reviews should be about functionality not form.
(I would have done it the 4 line way personally but no way would I have rejected the review on style.)
if (condition)
{
action
}
But then, I'm old.
|
|
|
|
|
MarkTJohnson wrote: But then, I'm old.
Me too! Which is probably why I get landed with working with archaic languages. 
MarkTJohnson wrote: Since both formats are used within the code base the person who bounced it was just wrong. Code reviews should be about functionality not form.
Yep. If this had been about something not working, (or if it was important enough to be documented as a standard), I would have changed it in a jif!
|
|
|
|
|
5teveH wrote: I would have changed it in a jif!
I do like peanut butter[^], but I'm a little unsure what to think of this. 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Absent a team style document, definitely stand your ground.
And certainly ignore weenies who try to quote from other teams' style documents. "But Microsoft says.." "We don't work for Microsoft, you weenie!"
I'm a whitespace supremicist as most of you know, so I nearly always use as much vertical space as I deem reasonable.
There are times, though, when I would use a series of one-liners. Usually if the tests and actions are very similar -- to show how they are similar.
if ( TestX ) { DoX() } ;
if ( TestY ) { DoY() } ;
if ( TestZ ) { DoX() } ;
...
I feel that in this situation, this style leads to more readable/understandable code and that copy/paste errors like above may be more easily spotted.
Does the language you're using not allow:
{do something} if {condition}
VAX BASIC V3.9-000
Ready
10 LET X = 42
20 PRINT "yes" IF X = 42
runnh
yes
Ready
modified 12-Aug-20 11:47am.
|
|
|
|
|
I'm with you on everything. Particularly like the VAX BASIC - not a million miles away from what I'm working with.
|
|
|
|
|
I think you may have won the battle, but lost the larger point of it all.
What you accomplished was to make yourself difficult to deal with. I don't think that's what you intended.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
