The only thing worse than code written using The Wrong Brace Style(tm)
-
Whitesmith's rules! I never seize to amaze over the triviality of this eternal style format discussion. Who is to say one style is better or worse than another? Is it not more important that the code is A. readable, B. intuitive, C. Bug Free! 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. This entire theme of discussion is in my years of writing code simply for small talk on coffee breaks and not really adding functionality in my personal opinion.
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.
-
... 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
The only answer is to switch to Fortran. If you still complain about K&R style after that, then you are far more resilient than I. :)
-
OriginalGriff wrote:
Reformat the whole lot to Whitesmiths style!
I came to C/C++ from turbo pascal - so naturally I did C/C++ in the Whitesmiths style ... I still guess that the primary reason for
void foo() {
}was the 12" monitors of yesteryears ... On the other hand, I guess the best reason for having a coding style-guide is to avoid wasting time discussing coding styles.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
The only answer is to switch to Fortran. If you still complain about K&R style after that, then you are far more resilient than I. :)
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
-
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.
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.
-
To me there often is much more to get upset on than brace styles. I can deal with every style (as long as it is the same style in the whole module of course). Meaningless variable names or code with a lot of untreated warnings from the compiler (deserts of trivial to solve warnings hiding the really important one) - that drives me nuts! Brace styles? No, not really...
jaybus56 wrote:
To me there often is much more to get upset on than brace styles
To me anyone that thinks bracing styles makes any difference at all has never worked in any of the industries that I have. There are a vast array of problems that measurably impact the entire process of delivering a useable piece of software. I can only suppose that people that think braces are significant do not deal with any but code and of course are completely unaware of formatting software.
-
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.
Maintenance programmers everywhere would like a word with you outside.
-
... 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 just wish all Version Control Systems would allow us to chose the brace formatting, as well as other formatting, and check the code out into the format we like and check it back in as the company standard. Then this battle could end. :)
-
Espen Harlinn wrote:
is to avoid wasting time discussing coding styles.
Yes, wasting time is much better spent on what the sport team did last weekend and what it will do next weekend.
jschell wrote:
Yes, wasting time is much better spent on what the sport team did last weekend and what it will do next weekend.
True, and everybody knows that we're wasting time, and not pretending to work ;P
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
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
-
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)
