|
If they ask where, should I say you're out standing in your field?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I can't stand it. You're fooling around, I can't stand it...
It was broke, so I fixed it.
|
|
|
|
|
As in late, overdue?
Okidoki.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
...weepy widdle Richard
|
|
|
|
|
"so many security holes, the Adobe Flash team has been called in to make it more secure" got me.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Weepy widdle Widchard
|
|
|
|
|
If a standard is a standard, it should be enforced as such, otherwise, it is just a suggestion. That being said, each organization needs to determine what they consider to be a standard.
At one of my previous employs, the 'standard' was to have the file name match the routine name, and since the overarching standard was 9 character file names, we ended up with routine names like:
SRVEXTPSM and SRVEXTSSM.
When I objected because I had no idea what the routine was supposed to do, I was told it was following the naming standard as though that was an explanation in itself.
|
|
|
|
|
Then you should hid on of these in there: EATSHTNDY or URSTNDSKS
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
In the absence of an established corporate coding standard, when editing an existing file, you should always adapt the style already used in the file. When creating a new file, you are free to go your own way, but consideration should be given to maintaining the same style as the other files in the folder (if there is a dominant style).
When I'm at home, I use the first style. At work, I'm lucky enough to working on my own stuff, so my preferred style is in force there as well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: In the absence of an established corporate coding standard, when editing an existing file, you should always adapt the style already used in the file.
Generally speaking, yes, and I'd never consider reformatting someone's code because they use a different style but I must confess that when I come across a really badly formatted SQL script - all random indents and inconsistent capitilisation combined with rubbish aliases and so forth - I just can't stop myself from tidying it up.
It's a little ironic in that I can't remember when I last tidied my desk (or my house for that matter) but messy code annoys the living daylights out of me.
|
|
|
|
|
I am forever reformatting other peoples SQL code (or generated SQL).
I have may own format rules, and once I get it in that format I can read it easy.
Unformatted, I can't make nor tail of it.
|
|
|
|
|
During my first year as a CompSci student, I got hold of a 'large' program: The 'Open Source' Pascal compiler, written in itself (yes, open source did exist before Linux! What Linux did was introducing the term) from ETH. In those days, a Pascal program couldn't be broken into modules: Everything had to be put into a single source file, even if it was a 20-30 kloc compiler.
This compiler source code was very consistent in the coding style of the tokenizer and parser. It was also very consistent in the semantic analysis. And it was highly consistent in the code generating functions. Three quite different, but very consistent coding styles, within a single source file. Even today I am surprised that they managed to keep it that way, without messing up each other's coding style. (I assume that there must have been three guys resposible for one part each.)
|
|
|
|
|
That story arc gets quite interesting...
veni bibi saltavi
|
|
|
|
|
I wouldn't convict him, might even help hold her down.
|
|
|
|
|
Here we go.... 
On a more serious note, I've seen both coding styles, and I despise #2. It just makes the code harder to read - to me. Am I just an old fart? I read an actual flaming rant about CamelCase (this is not) vs. camelCase (camels have humps in the middle). So, I finally get that.
But the curlies?
jumping into fox hole now.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I would have to agree. When you are looking at code you have never seen before, anything that makes it easier to understand what the code is doing is helpful. Separating out sections of code visually does help conceptualize program flow and structure.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
I am like you, love style #1, just can't stand style #2.
|
|
|
|
|
Yeah - I hate reading 1TB because it does it's damnedest to hide the open bracket.
I'm not fond of Allman either - I use Whitesmiths as it just feels more "together" to indent the brackets to the same level as the code block it's enclosing:
if (a == b)
{
c();
}
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
if (a == b)
{
c();
}
UGH! I really don't like that one at all.
I used to do things K&R style:
if (a == b) {
c();
}
but then I realised that that's a little bit ghastly, too. So for a long time I've been doing it this way ...
if (a == b)
{
c();
}
... and getting a little bit miffed with anyone that doesn't. It really makes code flow much more visible.
|
|
|
|
|
I like it because it's consistent - it's treating the indentation of the compound statement and the single statement in the same way.
But it's horses for courses! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I can see the logic behind it and I've worked with a couple of people that have used it but I find it murder on the eyeballs.
Needless to say, if that was the one that I used, I'd probably say the same about my way (i.e. the proper way  ).
|
|
|
|
|
I guess it depends on whether you consider the brackets part of the enclosing code block or the enclosed code block.
|
|
|
|
|
This! 
Stroustrup K&R is what I learned, and seems more logical to me (and easier on my eyes). Brackets separate a block of code that is performed as part of a command, so to my mind the opening bracket belongs on the same line as the command.
if (true) {
DoThis();
}
VB adopts K&R in its own way. Note the keywords and closing keywords:
If True Then
DoThis()
End If
But now I've probably hurt my case.
(edited to clarify the Stroustrup version of K&R)
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
