|
Better than usual today, awesome sky!
|
|
|
|
|
It's an image that really emphasises the meaning of a deadline[^].
|
|
|
|
|
I see the Grim Project Manager is at it again.
|
|
|
|
|
In my head, the man at the PC is Max Von Sydow, and he's playing Battle Chess[^]
|
|
|
|
|
|
That's brilliant. Weird, but brilliant!
|
|
|
|
|
|
... 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()
{
QmlDocument *qml = QmlDocument::create("asset:///main.qml");
qml->setContextProperty("_photoBomber", this);
if (!qml->hasErrors()) {
Page *appPage = qml->createRootObject<Page>();
if (appPage) {
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
|
|
|
|
|
What do you mean? Isn't that K&R?
This space intentionally left blank.
|
|
|
|
|
It's a mix of K&R and 1TBS 
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 – ∞)
|
|
|
|
|
I only see K&R. Maybe you need to show a bigger sample.
This space intentionally left blank.
|
|
|
|
|
I thought K&R put the function declaration on the previous line too.
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
|
|
|
|
|
Reformat the whole lot to Whitesmiths style!
Then you can breathe easy... 
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!
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
James Curran wrote: Oddly, what I truly detest in coding style ...
I'll buy that for a dollar.
Sorry, saw the ads for Robocop, pulled up the original and recently rewatched it.
Use of var object being assigned using 5 levels of subroutine calls, gack
|
|
|
|
|
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)
|
|
|
|
|
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".
|
|
|
|
|
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, for or while. 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 for
do {
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.
|
|
|
|
|
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)
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
