The only thing worse than code written using The Wrong Brace Style(tm)
-
Hmmmm would writing a mobile app in Fortran get me 15 minutes of fame by getting to the front page of hacker news? I'd say no, except that the person who wrote a web server framework in COBOL[^] succeeded.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
I wouldn't call that fame so much as infamy. I think that you would get some notoriety for it. You may get some public ridicule as well though even if you list that you did it on a lark. I don't know what mobile platform that actually has a compiler for Fortran though unless you roll your own for the NDK for Android. I guess someone has got that working: http://danilogiulianelli.blogspot.com/2013/02/how-to-build-gcc-fortran-cross-compiler.html[^]
-
MRJIT wrote:
Is it not more important that the code is A. readable...
Yes readability does matter, and that's exactly why brace style matters.
MRJIT wrote:
What I truly detest in coding style is all the code written as if programmers were paid by each line of code (ancient format of reimbursement) and everyone simply tries to fill a load of dead line space whilst appearing smart.
I have never understood the desire to save vertical space. Can anyone tell me why, in this day and age, vertical space is so important that it's worth sacrificing readability for? The best brace style is the most readable one, and also the one that is least likely to get mangled during refactoring. Allman, of course.
StatementTerminator wrote:
Can anyone tell me why, in this day and age, vertical space is so important ...
Putting a bunch of filler space does sacrifice readability when you have to scroll up and down to see what it is doing. I'm not complaining about putting a single statement on a single line. I'm talking about putting multiple lines of whitespace so you have 20 commands put in 100 lines of "code".
-
Member 10475170 wrote:
This leads to inconsistent formatting conventions and the mistaken idea that formatting is a matter of individual style rather than an engineering topic.
It is a matter of individual style. Conversely if you think it is not then presumably you have some objective data to back up the assertion that it provides measured benefit.
-
StatementTerminator wrote:
Can anyone tell me why, in this day and age, vertical space is so important ...
Putting a bunch of filler space does sacrifice readability when you have to scroll up and down to see what it is doing. I'm not complaining about putting a single statement on a single line. I'm talking about putting multiple lines of whitespace so you have 20 commands put in 100 lines of "code".
I can see that if there are a lot of pointless blank lines everywhere, I hate that myself. But putting an opening brace on its own line only adds one line per code block, and it doesn't add blank lines. Though I do think that blank lines can be useful to logically separate pieces of code, if used well. I don't know this for a fact, but I strongly suspect that K&R style was at least partly adopted to save space in print. It became popular during a time when people were learning programming from examples in actual printed books, and when you are including code samples in print the vertical space really matters, that's money. But with modern IDEs capable of collapsing code blocks, I don't see it as much of an issue.
-
Reformat the whole lot to Whitesmiths style! Then you can breathe easy... :laugh:
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
OriginalGriff wrote:
Reformat the whole lot to Whitesmiths style!
Then you can breathe easy... :laugh:+1 Isn't that the real 1TBS? :cool: Ralf
-
... is code that is written using a mix of brace styles. For my sins I'm investigating the possibility of porting one of my employer's apps to the BB10 platform; and most of the sample app code they've provided looks like this:
PhotoBomberApp::PhotoBomberApp()
{
// Create a QMLDocument and load it, using build patterns
QmlDocument *qml = QmlDocument::create("asset:///main.qml");qml->setContextProperty("\_photoBomber", this); if (!qml->hasErrors()) { // The application Page is created from QML. Page \*appPage = qml->createRootObject<Page>(); if (appPage) { // Set the application scene. Application::instance()->setScene(appPage); } }}
Some opening braces on their own line; others on the preceding line. **SPEW**[^]
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
K&R C was developed in the days when the Teletype ASR 33 was the standard keyboard/printer/paper tape reader/punch. The ASR 33 read and printed AT 10 CHARACTERS PER SECOND. Since it could take hours to compile and print a program listing, brevity was paramount. Spaces were important since each space took a 1/10 of a second to process; tabs were not usually used because tab settings were not consistent; and the program author was the maintainer, so understanding and style consistency were already learned. IMHO, C, C++, Java, JavaScript, and all their derivative languages are innately prone to error. I have spent countless unnecessary hours chasing non-obvious programming errors. In one case, I spent over 6 months chasing an "=" vs "==" in an if statement in a C program that was buried in an error recovery routine. Programs should be written, first for communications to yourself; second, to other programmers; and finally to the equipment. And part of communications is consistency in style. At last count, I have written programs and systems in over 40 languages, some of which where proprietary to equipment or application. They all have room for improvement! Just my thoughts
-
... is code that is written using a mix of brace styles. For my sins I'm investigating the possibility of porting one of my employer's apps to the BB10 platform; and most of the sample app code they've provided looks like this:
PhotoBomberApp::PhotoBomberApp()
{
// Create a QMLDocument and load it, using build patterns
QmlDocument *qml = QmlDocument::create("asset:///main.qml");qml->setContextProperty("\_photoBomber", this); if (!qml->hasErrors()) { // The application Page is created from QML. Page \*appPage = qml->createRootObject<Page>(); if (appPage) { // Set the application scene. Application::instance()->setScene(appPage); } }}
Some opening braces on their own line; others on the preceding line. **SPEW**[^]
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
I normally put the opening brace on the introductory statement line, but there are a number of functions I've written that do not follow this rule: those auto-generated by tools, and those that have too many arguments to put on one line. In the latter case, the main problem is that auto-formatting would not indent follow-up code correctly if I placed the opening brace on the last line of the argument list. But formatting works fine if I put it on a separate line. Life is compromise :| (yes, it's totally possible there are formatting tools better than the built-in VS editor, but I'm not going to clutter my toolbox just for 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)
-
MRJIT wrote:
What I truly detest in coding style is all the code written as if programmers were paid by each line of code (ancient format of reimbursement) and everyone simply tries to fill a load of dead line space whilst appearing smart.
Oddly, what I truly detest in coding style is the code packed so tightly as to be completely inscrutable to any other programmer --- to appear smart.
Truth, James
Spacing in code is similar to spacing in prose text documents: -make_the_lines_too_long_and_chances_are_you'll_skip_lines_when_reading,_because_you_need_to_move_your_view_to_the_left_and_right_too_much (there's a reason text in newspapers is split into columns!) - lines too short, and you'll run into difficulties recognizing the meaning of compound statements that were torn apart and split into multiple lines - put in too many blank lines, and you feel like you're working more scrolling than actually reading meaningful text - put in toofew blanksandspaces andyouhave difficulties recognizing thecontent(program) structure. Either way, people are different in how much separation they need to feel comfortable with a given text/program, or how little they need to make the text/program feel coherent. As an author/programmer, you need to find a sensible middle ground.
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)
-
I can see that if there are a lot of pointless blank lines everywhere, I hate that myself. But putting an opening brace on its own line only adds one line per code block, and it doesn't add blank lines. Though I do think that blank lines can be useful to logically separate pieces of code, if used well. I don't know this for a fact, but I strongly suspect that K&R style was at least partly adopted to save space in print. It became popular during a time when people were learning programming from examples in actual printed books, and when you are including code samples in print the vertical space really matters, that's money. But with modern IDEs capable of collapsing code blocks, I don't see it as much of an issue.
Usually an opening brace is preceded by a control statement such as
if,fororwhile. In those cases, I see no reason to place the opening brace on a separate line. These, by themselves, are easily recognizable as the start of a code block, especially when used in combination with reasonable indention. This is especially obvious fordo {
Or would you really prefer
do
{? As for collapsing code blocks, that suggestion isn't helpful. For one I collapse blocks only when it's contents aren't meaningful to the stuff I try to understand or fix - it doesn't make a difference how it's spaced or formatted in that case. Conversely, if parts of the block are relevant to me, I can't collapse it just because I don't like the formatting! K&R style was influenced a lot by the page format in printing, that is true. But today, in a similar fashion, it is much influenced by how much we can comfortably display on the screen - and that is not so much different at all!
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)
-
IMHO - the goal of formatting is to make the structure of the code visible, explicit, so the reader does not have to dig into the code and try to decipher its structure. Some people have the naive view that formatting as merely "pretty printing" or making the code neat and tidy. This leads to inconsistent formatting conventions and the mistaken idea that formatting is a matter of individual style rather than an engineering topic. Making the code pretty with an individual style only accomplishes half of the goal of making the structure explicit. It does not provide a basis for a consistent set of guidelines for the formatting.
The problem is that everyone experiences program structures in a subtly different way, and thus, if asked to format the code accordingly, will use different styles. It's not so much that the programmers format the code with the goal in mind to make it "look pretty" - they format it in the way that makes the most sense to their personal perception. The funny (or sad, depending on how you look at it) thing is, that the only objective argumments that you can get people to agree on are those related to "pretty printing", e. g. line length or width of indentation. It's pretty much impossible to agree on how to "correctly" express program structure in formating... :doh:
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)
-
Usually an opening brace is preceded by a control statement such as
if,fororwhile. In those cases, I see no reason to place the opening brace on a separate line. These, by themselves, are easily recognizable as the start of a code block, especially when used in combination with reasonable indention. This is especially obvious fordo {
Or would you really prefer
do
{? As for collapsing code blocks, that suggestion isn't helpful. For one I collapse blocks only when it's contents aren't meaningful to the stuff I try to understand or fix - it doesn't make a difference how it's spaced or formatted in that case. Conversely, if parts of the block are relevant to me, I can't collapse it just because I don't like the formatting! K&R style was influenced a lot by the page format in printing, that is true. But today, in a similar fashion, it is much influenced by how much we can comfortably display on the screen - and that is not so much different at all!
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)
Stefan_Lang wrote:
do {
Or would you really prefer
do
{?
I really do prefer the second one, actually. The reason is that the braces line up, making it easy to match up braces at a glance even when you have a lot of nested structures. It can also make debugging and refactoring easier, since you can quickly replace, comment, move around, etc. the control statement without messing with the braces. None of that is a huge deal however, and neither is the extra space used if you put it on a new line.
-
Stefan_Lang wrote:
do {
Or would you really prefer
do
{?
I really do prefer the second one, actually. The reason is that the braces line up, making it easy to match up braces at a glance even when you have a lot of nested structures. It can also make debugging and refactoring easier, since you can quickly replace, comment, move around, etc. the control statement without messing with the braces. None of that is a huge deal however, and neither is the extra space used if you put it on a new line.
As mentioned before, any of the control keywords are just as good for me to recognize the start of a code block as a brace, so that is not a good reason in my book. A control keyword lining up with a closing brace is all I need. This is all the more true when you have a lot of nested structures: it's hard to recognize the actual functionality of a code if half of the editor window shows only control statements and braces. As for refactoring, why would you move the control statement without the succeeding block? But as you said, none of this is a huge deal. For the code I currently deal with it probably would be a bad idea. It's old and riddled with control statements - it's hard to figure out what it does no matter the formatting, but not being able to see much of the relvant statements in the editor window because of added lines for braces would even be worse. For newly written code it probably would be much less of an issue either way.
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)
-
... is code that is written using a mix of brace styles. For my sins I'm investigating the possibility of porting one of my employer's apps to the BB10 platform; and most of the sample app code they've provided looks like this:
PhotoBomberApp::PhotoBomberApp()
{
// Create a QMLDocument and load it, using build patterns
QmlDocument *qml = QmlDocument::create("asset:///main.qml");qml->setContextProperty("\_photoBomber", this); if (!qml->hasErrors()) { // The application Page is created from QML. Page \*appPage = qml->createRootObject<Page>(); if (appPage) { // Set the application scene. Application::instance()->setScene(appPage); } }}
Some opening braces on their own line; others on the preceding line. **SPEW**[^]
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
