Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Indentation styles

Reply
Thread Tools

Indentation styles

 
 
Arne Vajhøj
Guest
Posts: n/a
 
      05-13-2013
On 5/7/2013 10:56 AM, Eric Sosman wrote:
> On 5/7/2013 10:23 AM, Stefan Ram wrote:
>> [...]
>> An indentation of just one space often is too small to be seen
>> clearly, because the natural width and form of characters
>> often varies by an amount that is not very much smaller than a
>> space. Therefore, the indentation should amount to at least
>> two positions. In order not to waste horizontal spaces, an
>> indentation of exactly two positions is chosen. This means,
>> that the left position of the next level is two larger than
>> the position of the directly enclosing level.
>> [...]

>
> I dimly recall reading, long ago, of someone's actual attempt
> to measure the readability of different indentation widths. Alas,
> I can no longer find the reference. I believe, though, that the
> experiments found two spaces too narrow, four spaces too wide, and
> eight spaces much too wide.
>
> Unfortunately, the remaining span includes two of the most
> prominent and pervasive numbers of all, and there's no hint as to
> which to use: The One True Best Indentation Width might be π or
> it might be e, and I expect the religious debates on the topic
> will rage endlessly. Personally, I adopt a tolerant stance: Use
> either e spaces or π spaces according to the teachings of your
> faith. Using anything else, though, would be heresy.


I sure someone has tried measuring what is optimal, but I
suspect that the difference were pretty small (for realistic
indentations).

But I am sure that it could be measured that the effect
of using the same indentation level in a file is huge and
I strongly suspect the same for using the same in a project.

Which leads to the normal conclusion:
* make a decision about indentation level and stick to it
* if there are no strong opinions about it then go with the
industry standard for that language (4 for Java)

Arne


 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      05-13-2013
On 5/8/2013 4:56 PM, Arved Sandstrom wrote:
> On 05/07/2013 06:29 PM, Martin Gregorie wrote:
>> On Tue, 07 May 2013 13:35:23 -0700, Wojtek wrote:
>>
>>> lipska the kat wrote :
>>>> On 07/05/13 17:11, Stefan Ram wrote:
>>>>> Daniele Futtorovic <(E-Mail Removed)> writes:
>>>>>> ... and subsequently decided that I didn't want to bar() after all,
>>>>>
>>>> <snippage>
>>>>
>>>>> ... What I do /not/ like that much is:
>>>>>
>>>>> void alpha() {
>>>>> beta(); gamma(); ...
>>>>>
>>>>>
>>>> Ah, my favorite style, I can't see why anyone would want or need
>>>> anything else. I've been known to reformat code with a particularly
>>>> irritating bracketing style but life is too short so generally now I
>>>> try to live with it. But really ...
>>>>
>>>> void alpha() {
>>>> beta(); gamma();
>>>> }
>>>>
>>>> Is a thing of beauty and a joy to behold, it's all you need
>>>
>>> Hmmm, I prefer my braces on their own line. In your style I am forever
>>> chasing my eye around the screen trying to find out if there is a brace,
>>> whereas a brace on a separate line stands out. YMMV but IMHO it is a
>>> faster way to read code.

>>
>> +1
>>

> Same here, +1. I am just not going to use different brace standards for
> Java, Perl, C, C++, C# etc.


Each language has its own standards, conventions and practices. I am
very skeptical about an attempt to format different languages identical.

Arne

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      05-13-2013
On 5/12/2013 10:04 PM, Arne Vajhøj wrote:
> On 5/7/2013 10:56 AM, Eric Sosman wrote:
>> On 5/7/2013 10:23 AM, Stefan Ram wrote:
>>> [...]
>>> An indentation of just one space often is too small to be seen
>>> clearly, because the natural width and form of characters
>>> often varies by an amount that is not very much smaller than a
>>> space. Therefore, the indentation should amount to at least
>>> two positions. In order not to waste horizontal spaces, an
>>> indentation of exactly two positions is chosen. This means,
>>> that the left position of the next level is two larger than
>>> the position of the directly enclosing level.
>>> [...]

>>
>> I dimly recall reading, long ago, of someone's actual attempt
>> to measure the readability of different indentation widths. Alas,
>> I can no longer find the reference. I believe, though, that the
>> experiments found two spaces too narrow, four spaces too wide, and
>> eight spaces much too wide.
>>
>> Unfortunately, the remaining span includes two of the most
>> prominent and pervasive numbers of all, and there's no hint as to
>> which to use: The One True Best Indentation Width might be π or
>> it might be e, and I expect the religious debates on the topic
>> will rage endlessly. Personally, I adopt a tolerant stance: Use
>> either e spaces or π spaces according to the teachings of your
>> faith. Using anything else, though, would be heresy.

>
> I sure someone has tried measuring what is optimal, but I
> suspect that the difference were pretty small (for realistic
> indentations).
>
> But I am sure that it could be measured that the effect
> of using the same indentation level in a file is huge and
> I strongly suspect the same for using the same in a project.
>
> Which leads to the normal conclusion:
> * make a decision about indentation level and stick to it
> * if there are no strong opinions about it then go with the
> industry standard for that language (4 for Java)


It would be both instructive and liberating, I think, to
adopt indentation widths that are multiples of i. Instead of
pushing the indented line to the right and thereby reducing
the amount of non-white horizontal space available, a pure
imaginary indent would move the text in a direction normal to
the page or display surface: Nearer to the viewer for c*i
with c>0, or further into the background for c<0. The sign
of c could be adjusted automatically by code inspection tools,
positive when the programmer is trying to study the excruciating
details of the code and wants to deep-dive on the interiors of
conditions and loops, or negative when the focus is on the Big
Picture and petty details shouldn't get in the way.

Given the two-dimensional nature of most display surfaces,
plus a third dimension toward or away from the viewer, one might
be tempted to employ indentation standards based on quaternions.
Any "one" so tempted is urged to seek psychiatric help. NOW.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      05-13-2013
On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhj <(E-Mail Removed)>
wrote:

[snip]

>Each language has its own standards, conventions and practices. I am
>very skeptical about an attempt to format different languages identical.


Not identical, but I have found that I can use very similar
standards across multiple languages.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      05-13-2013
On 5/13/2013 2:02 PM, Gene Wirchenko wrote:
> On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhj <(E-Mail Removed)>
> wrote:
>
> [snip]
>
>> Each language has its own standards, conventions and practices. I am
>> very skeptical about an attempt to format different languages identical.

>
> Not identical, but I have found that I can use very similar
> standards across multiple languages.


I am sure that you *can*.

But you will end up with N-1 or N languages being
formatted "unusual".

Arne


 
Reply With Quote
 
Jim Gibson
Guest
Posts: n/a
 
      05-14-2013
In article <51917188$0$32104$(E-Mail Removed)>, Arne Vajhj
<(E-Mail Removed)> wrote:

> On 5/13/2013 2:02 PM, Gene Wirchenko wrote:
> > On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhj <(E-Mail Removed)>
> > wrote:
> >
> > [snip]
> >
> >> Each language has its own standards, conventions and practices. I am
> >> very skeptical about an attempt to format different languages identical.

> >
> > Not identical, but I have found that I can use very similar
> > standards across multiple languages.

>
> I am sure that you *can*.
>
> But you will end up with N-1 or N languages being
> formatted "unusual".


To my limited knowledge Java is the only language whose originating
vendor publishes an "official" formatting standard. Usually, it is
individuals, groups, or organizations that develop formatting standards
and attempt to enforce them for some body of work.

Authors will use a consistent formatting style, and these can become
defacto standards (e.g., Kernighan and Ritchie, Stroustrup).

I, too, try to be consistent in formatting style when moving between
languages whenever possible, because it makes me more productive.

I have worked on projects with practically no standards, and others
with extensive standards, but they never seemed to be enforced.
Usually, the customer just wants the project finished, and never mind
about the format of the code.

--
Jim Gibson
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-14-2013
Jim Gibson wrote:
> Arne Vajh�j wrote:
>> I am sure that you *can* [use the same formatting style for different languages].
>>
>> But you will end up with N-1 or N languages being
>> formatted "unusual".

>
> To my limited knowledge Java is the only language whose originating
> vendor publishes an "official" formatting standard. Usually, it is
> individuals, groups, or organizations that develop formatting standards
> and attempt to enforce them for some body of work.
>
> Authors will use a consistent formatting style, and these can become
> defacto standards (e.g., Kernighan and Ritchie, Stroustrup).
>
> I, too, try to be consistent in formatting style when moving between
> languages whenever possible, because it makes me more productive.
>
> I have worked on projects with practically no standards, and others
> with extensive standards, but they never seemed to be enforced.
> Usually, the customer just wants the project finished, and never mind
> about the format of the code.


Here other programmers are "the customer", and we're here to help with source
code, or talk about other related matters where source code is part of the discussion.

Even if the language, such as C, doesn't have an official standard but it does have a de
facto standard, standards is standards.

Whatever your customer wants is irrelevant. Here we want to talk about code.. We are
not rigid about the "official" standard, but deviate too far from the social norm and you
lose audience. Your customer is not part of this process so why mention him?

It's about clear communication *with other programmers*. You want to use a sociopathic
style like Mr. Tilde's or Stefan's, you will run into communication difficulties. Just use the
standard format, for Chrissake!

No man is an island, so ask not for whom the bell tolls. It tolls for thee.

(Sorry, Mr. Donne.)

--
Lew
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      05-14-2013
On 5/13/2013 8:34 PM, Jim Gibson wrote:
> In article <51917188$0$32104$(E-Mail Removed)>, Arne Vajhj
> <(E-Mail Removed)> wrote:
>
>> On 5/13/2013 2:02 PM, Gene Wirchenko wrote:
>>> On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhj <(E-Mail Removed)>
>>> wrote:
>>>
>>> [snip]
>>>
>>>> Each language has its own standards, conventions and practices. I am
>>>> very skeptical about an attempt to format different languages identical.
>>>
>>> Not identical, but I have found that I can use very similar
>>> standards across multiple languages.

>>
>> I am sure that you *can*.
>>
>> But you will end up with N-1 or N languages being
>> formatted "unusual".

>
> To my limited knowledge Java is the only language whose originating
> vendor publishes an "official" formatting standard. Usually, it is
> individuals, groups, or organizations that develop formatting standards
> and attempt to enforce them for some body of work.
>
> Authors will use a consistent formatting style, and these can become
> defacto standards (e.g., Kernighan and Ritchie, Stroustrup).


It varies.

MS has published some conventions for C#. Guido has published some
guide for python.

But C and C++ has multiple widely used standards. I have seen many
different (but somewhat compatible) conventions for Ruby and PHP.

> I, too, try to be consistent in formatting style when moving between
> languages whenever possible, because it makes me more productive.


That is fine if you are the only person ever to work on the code.

But if somebody else is, then they will be more productive if
it is more "standard".

> I have worked on projects with practically no standards, and others
> with extensive standards, but they never seemed to be enforced.


There are tools to enforce if there is a will to enforce.

> Usually, the customer just wants the project finished, and never mind
> about the format of the code.


That has been seen.



But after 20 years with high annual maintenance cost it also happens
that they regret.

Arne


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      05-14-2013
Jim Gibson <(E-Mail Removed)> writes:
>To my limited knowledge Java is the only language whose originating
>vendor publishes an "official" formatting standard.


By convention, method names should be a verb in
lowercase or a multi-word name that begins with a verb
in lowercase, followed by adjectives, nouns, etc.

http://docs.oracle.com/javase/tutori...O/methods.html

The followers thus should write:

calculateSquareroot( calculateSquare( x )+ calculateSquare( y ))

. Now, Rob Pike has the correct guidelines for us:

Procedure names should reflect what they do;
function names should reflect what they return.

http://www.lysator.liu.se/c/pikestyle.html

, thus:

print( square( 2 ))

. print is a procedure, square is a function.
Life can be so simple.

Thus, one cannot reasonably follow all the Oracle
guidelines.

 
Reply With Quote
 
Daniele Futtorovic
Guest
Posts: n/a
 
      05-14-2013
On 14/05/2013 03:16, Stefan Ram allegedly wrote:
> Jim Gibson <(E-Mail Removed)> writes:
>> To my limited knowledge Java is the only language whose originating
>> vendor publishes an "official" formatting standard.

>
> By convention, method names should be a verb in
> lowercase or a multi-word name that begins with a verb
> in lowercase, followed by adjectives, nouns, etc.
>
> http://docs.oracle.com/javase/tutori...O/methods.html
>
> The followers thus should write:
>
> calculateSquareroot( calculateSquare( x )+ calculateSquare( y ))
>
> . Now, Rob Pike has the correct guidelines for us:
>
> Procedure names should reflect what they do;
> function names should reflect what they return.
>
> http://www.lysator.liu.se/c/pikestyle.html
>
> , thus:
>
> print( square( 2 ))


square( x ) creates a two-dimensional square with x pixel side length,
right?

> . print is a procedure, square is a function.
> Life can be so simple.
>
> Thus, one cannot reasonably follow all the Oracle
> guidelines.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Indentation styles for namespaces? Jorgen Grahn C++ 3 11-16-2011 11:15 PM
remove overall indentation preserving reletive indentation Jesse B. Ruby 2 03-27-2010 07:23 PM
DataList Indentation SJ ASP .Net 2 11-04-2005 12:16 AM
[Fwd: Indentation] jacov Java 0 07-22-2004 03:22 PM
Unwanted indentation Daan HTML 2 12-09-2003 10:09 PM



Advertisments