How can be concentrated multiple lines of C++ code in only one?

[mbozzi]

using a very unconventional style like that makes it more difficult to tell at a glance if the code is structured properly

We can tell a block closes when the next line isn't indented as much, and we can rely on the compiler to assure us that nothing's indented when it shouldn't be.

The only reasons for braces to go on their own line (IMO) are familiarity & tool support - nobody has an editor that supports this bracing style*, and nobody's used to it. And yes, it's hard to read at a glance for now, but I think most programmers would learn a new bracing style quite quickly.

*except those of us using Microsoft Word

[jonnin]

the .js style is fine in c++, but its just as hideous here as it is there. I would not. (.js was the first I know of to mangle brackets and call it 'best practice' but maybe they were not first, its just where I first saw it consistently.).

to me, all that is a big fat 'meh'. I wrote something that fixes busted code so that every { is matched to } in the same column. If the code annoys me, I can fix that, no big deal. And somewhere I have a batch file that will do every file in a pattern in a folder if someone managed to write something large in a weird format.

[mbozzi]

Closing-brackets-on-same-line is probably a characteristic of McCarthy's original LISP from the late 1950s.

Here's the original LISP 1 manual with an example of that style
http://history.siam.org/sup/Fox_1960_LISP.pdf

IDK if this is the origin of the syntax.

[helios]

We can tell a block closes when the next line isn't indented as much, and we can rely on the compiler to assure us that nothing's indented when it shouldn't be.

I'm not so sure this is true.

[jonnin]

The compiler does warn 'misleading indentation' at times but its inconsistent. It only seems to care in control statements on my compiler at least.

The LISP example is a good one, but I wonder if that is just 'paper saver' -- books or code that is printed (does anyone DO that anymore?! used to print reams of code back then) don't like to burn paper for pages and pages of lines that just have a { or } on them (rightfully).

[mbozzi]

I'm not so sure this is true.

So even if we can't rely on the compiler, Python programmers manage just fine without any braces at all. I don't understand how it would be more comprehensible if braces were added.

The LISP example is a good one, but I wonder if that is just 'paper saver' -- books or code that is printed (does anyone DO that anymore?! used to print reams of code back then) don't like to burn paper for pages and pages of lines that just have a { or } on them (rightfully).

LISP 1 was invented long before my time, so I suppose it's possible, but newer Lisps - Common Lisp, Racket, Clojure, Scheme, are all commonly written with lines that end in )))))))))).

[helios]

So even if we can't rely on the compiler, Python programmers manage just fine without any braces at all.

My argument wasn't about braces, but about making program structure obvious. In Python, program structure and indentation are one and the same. In C and C++ it's perfectly possible for the two to drift apart. I was arguing that using a familiar style that makes it completely obvious when this drift has happened is better.
I mean, if braces don't matter at all we could write like this, but I think we will all agree this is definitely a shitty style:

for (k = 1; k <= n; ++k)                                                        {
  flag = A[k][j];
  for (l = 1; l <= n + 1; ++l)                                                  {
    if (k != i)                                                                 {
      A[k][l] -= flag * A[i][l];
      ++mul; 
      ++sub;                                                                    }
                                                                                }
                                                                                }

[jonnin]

heh I had an OCD manager who made all his ;s out to the side like that so they were all in same column.

python compiler is more aware of the problem and somehow has a ton of heuristics to check it and warn the coder if it looks wrong. That aside, plenty of messed up python code where a scrambled indent took some time to debug. I started out liking python but the farther I got into it the more I hated it. I honestly can't stand it now. Partly the community... everyone is 'just use x library' ... but x library is of course written as inefficiently as is humanly possible for whatever it does, but its the only way to do it so you are stuck.

[helios]

I've been saying for a while that if it can be done in Python it can be done better in C#. Hell, a few weeks a go I translated some tests that were in Python to TypeScript. I simply cannot stand working with Python, or dynamic languages in general.

[MILLER XYL]

oh, so there is a way. BUT IT IS REALLY BAD

#include <bits/stdc++.h> 

or

#include <bits/stdtr1c++.h> 

[keskiverto]

tubar wrote:

I think remained residual the OLD CONCEPT of ECONOMIZING COMPUTING RESOURCES by writing each time SHORT lines of instructions. It remained an old school concept :).

Today the PC's are much more powerful, the memory does not restrain much today the programmer.

What?
These two have exact same number of bytes:

// A
int main() {foo(); bar();}

// B
int main()
{foo();
bar();}

I sense misconception.

tubar wrote:

And how work those instructions like std::cin, std::cout, std::endl;

Do you refer to the using-declaration? See https://en.cppreference.com/w/cpp/language/namespace#Using-declarations

The "using" is a language keyword. The compiler parses the using declarator-list ; statement
where declarator-list is comma-separated list of one or more declarators of the form typename(optional) nested-name-specifier unqualified-id.

tubar wrote:

Give working examples, pls. I want to note all the possibilities to compact the code lines.

Another example:
for(k=1; k<=n; k++){
flag = A[ k ][ j ];
for(l=1; l<=n+1; l++)
if(k != i){
A[k][l]= (A[k][l]) - flag * (A[i][l]);
mul++;
sub++;
}
}

You ask whether it is ok to remove one newline? I thought you desired:

//nowhitespace,forwehaveMEMORYnow:
for(k=1;k<=n;k++){flag=A[k][j];for(l=1;l<=n+1;l++)if(k!=i){A[k][l]=(A[k][l])-flag*(A[i][l]);mul++;sub++;}}

[dhayden]

Two thoughts on this.

First, whenever I need to examine code, the first thing I do is run it through a formatter (GNU indent) to put it in the format I like.

Second, although compilers derive the block structure from the braces, people derive it from the indentation. So the way I look at it, the braces are second-class citizens. They are only there because they have to be. Treat them with the disdain they deserve :). This is why I cuddle the braces as much as possible. I put the closing braces on lines by themselves because I don't think indent will let me do otherwise.