|
I do not see why the inner "if" is indented 2*4 spaces. I think it should line up with the first comment.
Small sidetrack:
Your style of commenting the end brace to indicate what it terminates can be very helpful in complex code. But what I long back to is the CHILL style: Any block can be labeled (the label applies to the block, not to a point in the code). If you repeat the label after the closing brace, the compiler will check it, giving a compilation error if it doesn't match. You could also break out to any outer block level, referring to the block label. Like
Outerloop: if (true) {
Innerloop: while (moreToDo) {
if (reasonToTerminate) exit Outerloop;
} Innerloop;
} Outerloop; This is far more readable and far safer. Unfortunately, it isn't straightforward to introduce it into the syntax of C class of languages. But as an emergency solution, your comments is a great alternative. Not necessarily for 2-line innermost loops/ifs, but certainly when the loop/if spans a dozen lines or more.
|
|
|
|
|
I think I fixed the (accidental) double indent.
As for the use of labels - no compiler differences to worry about if you keep it all in comment form. Maybe it's just me, but have a consistent convention across all of the coding languages is rather helpful at my age.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Certainly a valid argument - in particular when that is your only choice (but of course: Comment syntax varies across languages, and some languages don't even have an explicit block terminator to which you can affix your comment; you have to create a separate comment line, and must explain it by eg. "// end of if (condition)" so that it doesn't look as a commented-out if-statement.
And you don't get the compiler check. But if you can't get that, anyway, you certainly haven't lost anything.
I fully support you commenting style here. Yet I keep wishing that we had compiler support for it, and a simpler and cleaner syntax. ... Bemoaning what you can't get, begets nothing. Yet, moaning is a sort of self-comforting in hard times.
|
|
|
|
|
W∴ Balboos, GHB wrote: Opening brace on same line as conditional
Only in Java. C,C++ and C# it goes on the next line under the "i" character.
And if you would like to see something truly horrible with braces, take a look at some of @OriginalGriff's code.
|
|
|
|
|
Richard MacCutchan wrote: C,C++ and C# it goes on the next line under the "i" character. At least for C++--the others are irrelevant dreck--you are correct, and people should harken to someone so venerable.
|
|
|
|
|
Greg Utas wrote: dreck That was a common term when I lived in Manchester, but I have not heard it for years. Is it common in your city/province?
|
|
|
|
|
Not common in Ottawa at all. It came to mind because I saw it somewhere recently.
|
|
|
|
|
If you use a laptop or desktop computer made in the past few years, your operating system likely relied on a UEFI BIOS written almost entirely in "C" to detect and program the hardware. I would hardly call that irrelevant dreck!
FormerBIOSGuy
|
|
|
|
|
They're still dreck, but people somehow manage to overcome this and build useful things with them.
|
|
|
|
|
|
Richard MacCutchan wrote: Only in Java. C,C++ and C# it goes on the next line under the "i" character I was speaking in terms of coding professionals and should have made that clearer!
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: coding professionals All of whom adhere to their own personal standards.
|
|
|
|
|
Quote: Opening brace on same line as conditional
I used to prefer that style, but as I keep introducing more and more self-explanatory variable names, conditions tend to get long, and multiline conditions are not uncommon in my code. And then this happens:
if (my_condition && my_other_condition ||
use_other_condition_flag && other_condition) {
do_something();
} and suddenly the egyptian style didn't seem to be so great anymore! Compare to this:
if (my_condition && my_other_condition ||
use_other_condition_flag && other_condition)
{
do_something();
} Here the actual if code block is much easier to recognize!
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)
|
|
|
|
|
Except I would have indented the do_something();
It's really all personal eye-candy - I really don't like all of (almost) empty lines breaking things ups - just indented blocks do adequately.
For really long conditionals (sometimes it happens) I actually will "format" them, themselves, so as to create a more visually orderly condition - somewhat as you did although possibly more than one per line if they're not complex.
Most important of all: consistency to aid in updates, help track bugs, and avoid bugs in the first place. The last seems to always somehow be theoretical.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
When code was a bunch of if/gotos, you never indented more than 1 level!
Probably goes back to basic style guides for non-code writing as well.
|
|
|
|
|
I think that's kind of the point of the pro-tab crowd: you can set your preferences to whatever works for you.
BTW, I agree that 8 is too much.
|
|
|
|
|
Since "way back", I have always used a 4 spaces tab setting on all C (and Perl, C++, etc) languages, 8 spaces tabs or no tabs on everything else. And so did pretty much everyone else in those days.
|
|
|
|
|
I believe the convention goes back typewriters, which may have picked it up from typesetting. Approximately 80 characters per typewritten line on a standard sheet of paper. If you break that into 10 columns (so you can make tables), you start a new column every 8 characters. So when typing a table, you would enter something, hit the tab key which would take you over the "remaining" amount of the 8 characters, then type your next column. If you just hit the tab key, you went over 8 characters to leave that entry in the column blank.
Come on people - I'm not the only "old fart" around here. Surely I'm not the only one that learned to type on a typewriter rather than a teletype or PC keyboard!
|
|
|
|
|
|
I assume he'll also be going on a diet.
Monday starts Diarrhea awareness week, runs until Friday!
JaxCoder.com
|
|
|
|
|
?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
As you observe activity of my work, doesn't that prove I'm displaying?
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
You are displaying and not displaying at the same time; you are both, until I look.
Before mankind observed the universe, there was chaos.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You have just invented "Shrodinger's Work" !
|
|
|
|
|
Eddy Vluggen wrote: Before mankind observed the universe, there was chaos.
And afterwards?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|