Indentation style: public/private/protected/case

[Kenneth Porter]

I'm un-indenting the constructs mentioned in the subject line to align
with the enclosing braces:

switch (expression)
{
case 1:
statement1;
case 2;
statement2;
default:
defaultstatement;
|

class Class
{
public:
declaration1;
private:
declaration2;
};

I'm finding myself in an edit war with a coworker. (A result of default
editor settings, not a philosophical conflict.) His style is set to
indent the colon-terminated keywords, and then indent the controlled
statements/declarations an additional level.

class Class
{
public:
declaration1;
private:
declaration2;
};

Is there value in the double-indenting style? I find it squeezes out yet
more precious horizontal space without making the code significantly more
readable. Do others find it more readable? What's common practice here?

I just want to establish consistency so that our change control system
doesn't show the whole file changed everytime one of us checks a file in
with different indenting.

 

[Jim Langston]

I'm un-indenting the constructs mentioned in the subject line to align
with the enclosing braces:

switch (expression)
{
case 1:
statement1;
case 2;
statement2;
default:
defaultstatement;
|

class Class
{
public:
declaration1;
private:
declaration2;
};

I'm finding myself in an edit war with a coworker. (A result of default
editor settings, not a philosophical conflict.) His style is set to
indent the colon-terminated keywords, and then indent the controlled
statements/declarations an additional level.

class Class
{
public:
declaration1;
private:
declaration2;
};

Is there value in the double-indenting style? I find it squeezes out yet
more precious horizontal space without making the code significantly more
readable. Do others find it more readable? What's common practice here?

I just want to establish consistency so that our change control system
doesn't show the whole file changed everytime one of us checks a file in
with different indenting.

I was once in an editing war with a boss. He would indent tabed (8 spaced
tabs) and I would put in 3 spaces. I felt his was hard to read, he felt
mine. Finally, he said, "You leave my code alone, I'll leave your code
alone" and we did.

If you can't agree to agree, at least agree to disagree.

 

[Guest]

I'm un-indenting the constructs mentioned in the subject line to align
with the enclosing braces:

switch (expression)
{
case 1:
statement1;
case 2;
statement2;
default:
defaultstatement;
|

class Class
{
public:
declaration1;
private:
declaration2;
};

I'm finding myself in an edit war with a coworker. (A result of default
editor settings, not a philosophical conflict.) His style is set to
indent the colon-terminated keywords, and then indent the controlled
statements/declarations an additional level.

class Class
{
public:
declaration1;
private:
declaration2;
};

Is there value in the double-indenting style? I find it squeezes out yet
more precious horizontal space without making the code significantly more
readable. Do others find it more readable? What's common practice here?

I just want to establish consistency so that our change control system
doesn't show the whole file changed everytime one of us checks a file in
with different indenting.

Select an editor that can auto-indent the code and use the standard that
it uses. Indentation wars are stupid, there are a few styles that are
hard to read but most are just that, styles. For that reason you should
select a style that is supported by your editor, that way you do not
have to worry about it.

 

[Bo Persson]

Kenneth Porter wrote:
:: I'm un-indenting the constructs mentioned in the subject line to
:: align with the enclosing braces:
::
:: switch (expression)
:: {
:: case 1:
:: statement1;
:: case 2;
:: statement2;
:: default:
:: defaultstatement;
:::
::
:: class Class
:: {
:: public:
:: declaration1;
:: private:
:: declaration2;
:: };
::
:: I'm finding myself in an edit war with a coworker. (A result of
:: default editor settings, not a philosophical conflict.) His style
:: is set to indent the colon-terminated keywords, and then indent
:: the controlled statements/declarations an additional level.
::
:: class Class
:: {
:: public:
:: declaration1;
:: private:
:: declaration2;
:: };

I find this particular code harder to read, because there is a two
level distance between declaration2 and the final brace of the class.

That is about the only reason why I personally like your indentation
better.

::
:: I just want to establish consistency so that our change control
:: system doesn't show the whole file changed everytime one of us
:: checks a file in with different indenting.

Can't you have your editors or you version control system save the
files in a common format?


Bo Persson

 

[Kenneth Porter]

Can't you have your editors or you version control system save the
files in a common format?

We use the same editor. It's just that his apparently has the default
settings, while mine has been tweaked to remove the additional indent.
Neither of is wedded (yet) to a style, but I want to make sure my style
isn't deficient in some way before I go make him change his to match.

The version control system is Subversion. It doesn't care about the format
of files. It can be told that a file is text and will do line-ending
conversion but it won't re-indent files, because that's potentially a
higher-level semantic change. (For example, that would really screw up
Python source, where indentation is part of the syntax.)

 

[James Kanze]

"Bo Persson" <[email protected]> wrote innews:[email protected]:

[...]

The version control system is Subversion. It doesn't care about the format
of files. It can be told that a file is text and will do line-ending
conversion but it won't re-indent files, because that's potentially a
higher-level semantic change. (For example, that would really screw up
Python source, where indentation is part of the syntax.)

If the version control system doesn't allow you to insert
scripts before insertion, it's time to replace it with something
else. Immediately. You definitly want to automatically run
your unit tests before check in, and reject the check in if they
fail. If you're able to do this, it's trivial to insert an
additional tool to reformat.

 

[Kenneth Porter]

If the version control system doesn't allow you to insert
scripts before insertion, it's time to replace it with something
else. Immediately. You definitly want to automatically run
your unit tests before check in, and reject the check in if they
fail. If you're able to do this, it's trivial to insert an
additional tool to reformat.

In fact Subversion has a pre-commit hook (on the server side), but the hook
won't modify the committed files. It can only reject them if they don't
meet your criteria.

Subversion does have eol conversion (if you tag the file with an eol
"property") but I'm not sure if this is done on the client or server.

 

[Kenneth Porter]

From the Subversion mailing list:

http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33887

Just for your info, there is no sane way to modify the data that was
committed. The reason is that if you modified the data that a use
committed, the user's local data would be out of sync with the data on
the server, leading to all kinds of trouble. Yes, there are possible
solutions, but these are rather complicated and not in Subversion.

That is the reason why you can only reject malformatted data, but not
format it yourself.

There are wrapper programs that might be able to do this, such as Tortoise
and Ankh.

 

[James Kanze]

@q5g2000prf.googlegroups.com:

In fact Subversion has a pre-commit hook (on the server side),
but the hook won't modify the committed files. It can only
reject them if they don't meet your criteria.

That's interesting.

It did occur to me after posting that regardless of what the
version control offers, it's pretty straightforeward to wrap its
commands in a script---that can do whatever you want. I've
worked in places which used very primitive version control
systems (CVS, SCCS, etc.), and in such cases, the basic commands
were always wrapped in some sort of script---it would be
accurate to say that we actually wrote our own version control
system, using SCCS or CVS as the underlying machine.

Subversion does have eol conversion (if you tag the file with
an eol "property") but I'm not sure if this is done on the
client or server.

Eol represents another bag of worms. Think of what happens
on shared file systems. In practice, the simplest solution is
just to configure everything to use the Unix convention, since
this causes no problems with any of the Windows toolset as well.
(The editors I use on Windows have options to allow writing
files back using either convention.) I've no experience with
Mac, but given that modern Mac has Unix under the hood, I would
presume that the Unix convention works there as well. And of
course, for IBM mainframes and the like, you have to transcode
anyway, since they expect EBCDIC.

 

[Kenneth Porter]

I've worked in places which used very primitive version control
systems (CVS, SCCS, etc.), and in such cases, the basic commands were
always wrapped in some sort of script---it would be accurate to say
that we actually wrote our own version control system, using SCCS or
CVS as the underlying machine.

A good system should be modular with narrow coupling, just like a C++
program.

Subversion, like CVS, is a module that provides client/server version
control, and little else. You can then integrate it into a higher-level
change management (CM) system that does more sophisticated things, like re-
indenting sources.

Tortoise is a Windows GUI that integrates the Subversion libraries into
Windows Explorer.

Ankh does the same for the Visual Studio IDE.