|
the apparent width of 8 spaces will vary with font, display, screen resolution, app settings, programmer caffeine level, etc.
to express typographic design in a device independent way, we have tab, and the relative-proportion glyphs 'em and 'en dashes and spaces, etc.
in terms of the long evolution of type in the world of paper and print, typography in IDE's is a johnny-come-lately. before the "rise" of desktop publishing from 1960's onward, very few people had any idea of the aesthetics of type design, letterform/glyph anatomy, leading, kerning, etc.
old conventions like paragraph first-line indentation go back to the days of illuminated manuscripts, where a scribe would insert a marker called a pilcrow that a special scribe, a rubucator, would insert an illustration in.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
My take is that horizontal space is often wasted, and vertical space used too miserly. I loathe tabs and convert them to 3 spaces, which is enough of an offset for me to see indentation levels clearly.
|
|
|
|
|
lw@zi wrote: I was wondering why they were talking about tab = 8 spaces. What do you mean "we" ?
For a coding application I set tab at four, or even two. It's a bit font-dependent.
As for your code sample, all eyes are different, but for your 4-space tab I'd make it:
if (true) {
if (false) {
}
} I particularly draw your attention to two three conventions:
- Opening brace on same line as conditional
- Closing brace under begfinning of its conditional
- Comment containing matching conditional clearly identifies the end
The labling of the closing brace is invaluable when you look at the stuff some day further along in history and need to see what's what very quickly (or at least more quickly).
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 |
modified 4-Mar-20 9:46am.
|
|
|
|
|
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
|
|
|
|