Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23893 > unrolled thread

Re: Indentation styles

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Indentation styles Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-07 17:56 +0200
    Re: Indentation styles lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-07 17:39 +0100
      Re: Indentation styles Wojtek <nowhere@a.com> - 2013-05-07 13:35 -0700
        Re: Indentation styles Martin Gregorie <martin@address-in-sig.invalid> - 2013-05-07 21:29 +0000
          Re: Indentation styles Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-05-08 17:56 -0300
            Re: Indentation styles Arne Vajhøj <arne@vajhoej.dk> - 2013-05-12 22:07 -0400
              Re: Indentation styles Gene Wirchenko <genew@telus.net> - 2013-05-13 11:02 -0700
                Re: Indentation styles Arne Vajhøj <arne@vajhoej.dk> - 2013-05-13 19:04 -0400
                  Re: Indentation styles Jim Gibson <jimsgibson@gmail.com> - 2013-05-13 17:34 -0700
                    Re: Indentation styles Lew <lewbloch@gmail.com> - 2013-05-13 17:44 -0700
                      Re: Indentation styles lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-05-14 09:26 +0100
                      Re: Indentation styles Jim Gibson <jimsgibson@gmail.com> - 2013-05-14 10:23 -0700
                        Re: Indentation styles Arne Vajhøj <arne@vajhoej.dk> - 2013-05-17 19:43 -0400
                      Re: Indentation styles Arne Vajhøj <arne@vajhoej.dk> - 2013-05-17 19:42 -0400
                    Re: Indentation styles Arne Vajhøj <arne@vajhoej.dk> - 2013-05-13 20:53 -0400
                    Re: Indentation styles Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-14 13:07 +0200
                      Re: Indentation styles Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-05-15 18:47 -0300
                        Re: Indentation styles Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-16 05:28 +0200
                          Re: Indentation styles Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-05-17 19:44 -0300
                    Re: Indentation styles Stanimir Stamenkov <s7an10@netscape.net> - 2013-05-26 20:35 +0300
        Re: Indentation styles Joerg Meier <joergmmeier@arcor.de> - 2013-05-08 00:00 +0200
        Re: Indentation styles Gene Wirchenko <genew@telus.net> - 2013-05-08 11:12 -0700
    Re: Indentation styles Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-05-07 23:57 +0200

Page 1 of 2  [1] 2  Next page →

#23893 — Re: Indentation styles

On 07/05/2013 16:23, Stefan Ram allegedly wrote:
> markspace <markspace@nospam.nospam> writes:
>> I don't see why code can't be formatted for its intended audience either.
> 
>   The formatting too is part of the message I want to convey,
>   so to me it would not be the same message anymore.

<snippalot />

All fair and well, but one aspect that you have not covered and that to
me is of import, is the comment-out-ability. That is, because I care
about being able easily to comment-out/decomment stuff, I usually don't
mix parts of the block descriptor (flow-control, method descriptor,
etc.) and statements.

To exemplify, if I wrote...
  void foo()
  { bar();
    boom();
    bang();
  }
... and subsequently decided that I didn't want to bar() after all, I'd
have to alter the structure. So I'll either write:
  void foo()
  {
    bar();
    boom();
    bang();
  }
or
  void foo() {
    bar();
    boom();
    bang();
  }

While I understand, rationally, the arguments for the former, for some
eerie reason it hasn't really caught on to me, and I've mainly stuck to
the latter. But YMMV.

-- 
DF.

[toc] | [next] | [standalone]

#23898

On 07/05/13 17:11, Stefan Ram wrote:
> Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> 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 :-)

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#23903

lipska the kat wrote :
> On 07/05/13 17:11, Stefan Ram wrote:
>> Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> 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.

-- 
Wojtek :-)

[toc] | [prev] | [next] | [standalone]

#23904

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 <da.futt.news@laposte-dot-net.invalid> 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


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#23948

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 <da.futt.news@laposte-dot-net.invalid> 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. And I do find the symmetric version with 
brace pairs on their own lines to be more readable. It also makes sense 
because quite often you need to leave some WS between the test or 
whatever that creates the block, and the lead statement of the body...so 
why not drop the leading brace down to accomplish that?

AHS

[toc] | [prev] | [next] | [standalone]

#24026

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 <da.futt.news@laposte-dot-net.invalid> 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

[toc] | [prev] | [next] | [standalone]

#24039

On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhøj <arne@vajhoej.dk>
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

[toc] | [prev] | [next] | [standalone]

#24041

On 5/13/2013 2:02 PM, Gene Wirchenko wrote:
> On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhøj <arne@vajhoej.dk>
> 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

[toc] | [prev] | [next] | [standalone]

#24049

In article <51917188$0$32104$14726298@news.sunsite.dk>, Arne Vajhøj
<arne@vajhoej.dk> wrote:

> On 5/13/2013 2:02 PM, Gene Wirchenko wrote:
> > On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhøj <arne@vajhoej.dk>
> > 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

[toc] | [prev] | [next] | [standalone]

#24050

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

[toc] | [prev] | [next] | [standalone]

#24053

On 14/05/13 01:44, Lew wrote:
> 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?

You whine about people disagreeing with you then you come out with this 
old bollocks. There's no need for it, it was just a passing comment yet 
you seem to feel it needs a dose of your usual vitriol and criticism.

It was a perfectly valid point in the context of a discussion on code 
style. Enlightened customers may insist on a certain standard, less 
enlightened ones may not and only care about getting the software so 
that they may use it to enhance their business.

Actually there is a whole discussion around the difference between what 
a customer wants and what they actually need but I suppose that *is* 
slightly OT, no need for the sniping though is there?

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24058

In article <b0291da6-a9ad-4848-a9c0-e357f5eb6de5@googlegroups.com>, Lew
<lewbloch@gmail.com> wrote:

> Jim Gibson wrote:
> > 
> > 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. 

I wasn't talking about posting code to comp.lang.java.programmer. I was
discussing the use of programming standards in general. I haven't had
occasion yet to post any code here, but if I do, you can be assured it
will follow Java standards, just to avoid criticism from the
small-minded among you.

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

"I believe in standards.  Everyone should have one." - George Morrow

> 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!

My format is better than the standard format. It is not, however,
"sociopathic". Just works for me.

-- 
Jim Gibson

[toc] | [prev] | [next] | [standalone]

#24123

On 5/14/2013 1:23 PM, Jim Gibson wrote:
> In article <b0291da6-a9ad-4848-a9c0-e357f5eb6de5@googlegroups.com>, Lew
> <lewbloch@gmail.com> wrote:
>> Jim Gibson wrote:
>>>
>>> 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.
>
> I wasn't talking about posting code to comp.lang.java.programmer. I was
> discussing the use of programming standards in general. I haven't had
> occasion yet to post any code here, but if I do, you can be assured it
> will follow Java standards, just to avoid criticism from the
> small-minded among you.

Right decision wrong reason. IMHO.

Arne

[toc] | [prev] | [next] | [standalone]

#24122

On 5/13/2013 8:44 PM, Lew wrote:
> Even if the language, such as C, doesn't have an official standard but it does have a de
> facto standard,

Really?

What is it?

I mean GNU style says indent 2, K&R styles says indent 4 and Linux
kernel style says indent 8.

Which one is the de facto standard?

> 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.

Playing psychiatrist again?

>                                                                           Just use the
> standard format,

That one I agree with!

Arne

[toc] | [prev] | [next] | [standalone]

#24051

On 5/13/2013 8:34 PM, Jim Gibson wrote:
> In article <51917188$0$32104$14726298@news.sunsite.dk>, Arne Vajhøj
> <arne@vajhoej.dk> wrote:
>
>> On 5/13/2013 2:02 PM, Gene Wirchenko wrote:
>>> On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhøj <arne@vajhoej.dk>
>>> 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

[toc] | [prev] | [next] | [standalone]

#24055

On 14/05/2013 03:16, Stefan Ram allegedly wrote:
> Jim Gibson <jimsgibson@gmail.com> 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/tutorial/java/javaOO/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.

[toc] | [prev] | [next] | [standalone]

#24079

On 05/14/2013 08:07 AM, Daniele Futtorovic wrote:
> On 14/05/2013 03:16, Stefan Ram allegedly wrote:
>> Jim Gibson <jimsgibson@gmail.com> 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/tutorial/java/javaOO/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?

In the context of a graphing package I might expect that. In the context 
of a math package I would not.

AHS

[toc] | [prev] | [next] | [standalone]

#24083

On 15/05/2013 23:47, Arved Sandstrom allegedly wrote:
> On 05/14/2013 08:07 AM, Daniele Futtorovic wrote:
>> On 14/05/2013 03:16, Stefan Ram allegedly wrote:
>>> Jim Gibson <jimsgibson@gmail.com> 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/tutorial/java/javaOO/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?
> 
> In the context of a graphing package I might expect that. In the context
> of a math package I would not.

Which package the method belongs to, or what a package is "about", is
hardly a generally readily discernible information. And you might have a
package that does both...

But generally speaking, you see what I mean, don't you? That condensed
form is ambiguous; the further condensed, the more ambiguous any form
will be. There is beauty and elegance in subtlety; there is a lot of
onanism in it, too. For our trade, I believe the Jav has it right in
recommending more paraphrasing and hence more determinism -- especially
readily apparent determinism.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#24117

On 05/16/2013 12:28 AM, Daniele Futtorovic wrote:
> On 15/05/2013 23:47, Arved Sandstrom allegedly wrote:
>> On 05/14/2013 08:07 AM, Daniele Futtorovic wrote:
>>> On 14/05/2013 03:16, Stefan Ram allegedly wrote:
>>>> Jim Gibson <jimsgibson@gmail.com> 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/tutorial/java/javaOO/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?
>>
>> In the context of a graphing package I might expect that. In the context
>> of a math package I would not.
>
> Which package the method belongs to, or what a package is "about", is
> hardly a generally readily discernible information. And you might have a
> package that does both...
>
> But generally speaking, you see what I mean, don't you? That condensed
> form is ambiguous; the further condensed, the more ambiguous any form
> will be. There is beauty and elegance in subtlety; there is a lot of
> onanism in it, too. For our trade, I believe the Jav has it right in
> recommending more paraphrasing and hence more determinism -- especially
> readily apparent determinism.
>
Bad choice of words on my part, my headspace when I wrote that wasn't 
Java, it was more general. Think "software package", not "Java package".

In general I agree with you. I would understand 'square' as a method 
name to mean the mathematical operation, provided that the argument type 
made sense. This actually follows Pike's guidelines: 'square' used as a 
verb with a numerical (integer, real, complex, matrix etc) argument has 
one well-known meaning. It's not actually ambiguous at all.

But if the method were to do something different other than squaring a 
number, yes, it should have a better name.

AHS

[toc] | [prev] | [next] | [standalone]

#24183

14 May 2013 01:16:41 GMT, /Stefan Ram/:

>        »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/tutorial/java/javaOO/methods.html
>
>    The followers thus should write:
>
> calculateSquareroot( calculateSquare( x )+ calculateSquare( y ))

JLS, Chapter 6. Names 
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html>:

| We recommend these conventions for use in all programs written in
| the Java programming language. However, these conventions should
| not be followed slavishly if long-held conventional usage
| dictates otherwise. So, for example, the sin and cos methods of
| the class java.lang.Math have mathematically conventional names,
| even though these method names flout the convention suggested
| here because they are short and are not verbs.

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web