Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Indentation styles
101 views
Skip to first unread message
Message has been deleted
Eric Sosman
May 7, 2013, 10:56:51 AM5/7/13
to
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. :)
--
Eric Sosman
eso...@comcast-dot-net.invalid
>[...]
> 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. :)
--
Eric Sosman
eso...@comcast-dot-net.invalid
Daniele Futtorovic
May 7, 2013, 11:56:01 AM5/7/13
to
On 07/05/2013 16:23, Stefan Ram allegedly wrote:
> markspace <mark...@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.
> markspace <mark...@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.
Message has been deleted
lipska the kat
May 7, 2013, 12:39:14 PM5/7/13
to
On 07/05/13 17:11, Stefan Ram wrote:
> ... 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
> Daniele Futtorovic <da.fut...@laposte-dot-net.invalid> writes:
>> ... and subsequently decided that I didn't want to bar() after all,
>
<snippage>
>> ... and subsequently decided that I didn't want to bar() after all,
>
> ... 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
Wojtek
May 7, 2013, 4:35:23 PM5/7/13
to
lipska the kat wrote :
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 :-)
> On 07/05/13 17:11, Stefan Ram wrote:
>> Daniele Futtorovic <da.fut...@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
>> Daniele Futtorovic <da.fut...@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 :-)
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 :-)
Martin Gregorie
May 7, 2013, 5:29:35 PM5/7/13
to
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Daniele Futtorovic
May 7, 2013, 5:57:42 PM5/7/13
to
On 07/05/2013 18:11, Stefan Ram allegedly wrote:
> Daniele Futtorovic <da.fut...@laposte-dot-net.invalid> writes:
> Daniele Futtorovic <da.fut...@laposte-dot-net.invalid> writes:
>> ... and subsequently decided that I didn't want to bar() after all,
>
> In this case one can edit it from
>
>
> void alpha()
> { beta();
> gamma(); ...
>
> to either
> void alpha()
> { beta();
> gamma(); ...
>
>
> void alpha()
> { // beta();
> gamma(); ...
But putting those two slashes in (or removing them) is much more
cumbersome than [navigate to line] -> [ ctrl + / ].
<snip />
> What I do /not/ like that much is:
>
> void alpha() {
> beta();
> gamma(); ...
--
DF.
Joerg Meier
May 7, 2013, 6:00:18 PM5/7/13
to
On Tue, 07 May 2013 13:35:23 -0700, Wojtek wrote:
> 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.
Personally, I moved on since the stone age and use a code formatter. So I
> 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.
don't need to hunt for the opening bracket: I can tell it's there because
the code in the line under it is indented. I heartily recommend it ;)
Liebe Gruesse,
Joerg
--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
Gene Wirchenko
May 8, 2013, 2:12:26 PM5/8/13
to
[snip]
>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.
When scanning code for a section, I typically read just the left
part. With braces on their own line, this makes it much easier to
check nesting.
Sincerely,
Gene Wirchenko
>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.
part. With braces on their own line, this makes it much easier to
check nesting.
Sincerely,
Gene Wirchenko
Arved Sandstrom
May 8, 2013, 4:56:31 PM5/8/13
to
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
Arne Vajhøj
May 12, 2013, 10:01:04 PM5/12/13
to
On 5/7/2013 10:23 AM, Stefan Ram wrote:
> markspace <mark...@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.
>
> If someone is paying me to write code, he can get any format
> markspace <mark...@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.
>
> from me that he likes. But on the Usenet I enjoy the freedom
> to use the indentation style that I deem best, as explained below:
Usenet is free. Period.
But that does not change that it is impolite to ask people to
look at some code that is not formatted to make it easy for
them to read.
And even if the only reason is that they are used to another
style does not change that.
If not asking anyone for help but instead providing help,
then there is a moral aspect of what one learn people. Since
you code does not have /* do not format code like this at home */,
then someone could be mislead to think that it was OK to format
like that.
Arne
Arne Vajhøj
May 12, 2013, 10:04:59 PM5/12/13
to
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
Arne Vajhøj
May 12, 2013, 10:07:42 PM5/12/13
to
very skeptical about an attempt to format different languages identical.
Arne
Eric Sosman
May 12, 2013, 11:21:03 PM5/12/13
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
eso...@comcast-dot-net.invalid
Gene Wirchenko
May 13, 2013, 2:02:32 PM5/13/13
to
On Sun, 12 May 2013 22:07:42 -0400, Arne Vajh�j <ar...@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
wrote:
[snip]
>Each language has its own standards, conventions and practices. I am
>very skeptical about an attempt to format different languages identical.
standards across multiple languages.
Sincerely,
Gene Wirchenko
Arne Vajhøj
May 13, 2013, 7:04:41 PM5/13/13
to
On 5/13/2013 2:02 PM, Gene Wirchenko wrote:
> On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhøj <ar...@vajhoej.dk>
But you will end up with N-1 or N languages being
formatted "unusual".
Arne
> On Sun, 12 May 2013 22:07:42 -0400, Arne Vajhøj <ar...@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*.
>
> [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.
But you will end up with N-1 or N languages being
formatted "unusual".
Arne
Jim Gibson
May 13, 2013, 8:34:08 PM5/13/13
to
In article <51917188$0$32104$1472...@news.sunsite.dk>, Arne Vajh�j
> > On Sun, 12 May 2013 22:07:42 -0400, Arne Vajh�j <ar...@vajhoej.dk>
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
> > On Sun, 12 May 2013 22:07:42 -0400, Arne Vajh�j <ar...@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
> >
> > [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".
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
Lew
May 13, 2013, 8:44:06 PM5/13/13
to
Jim Gibson wrote:
> Arne Vajh�j wrote:
>> I am sure that you *can* [use the same formatting style for different languages].
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
> 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
>> 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.
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
Arne Vajhøj
May 13, 2013, 8:53:02 PM5/13/13
to
On 5/13/2013 8:34 PM, Jim Gibson wrote:
> In article <51917188$0$32104$1472...@news.sunsite.dk>, Arne Vajh�j
> <ar...@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 <ar...@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.
> In article <51917188$0$32104$1472...@news.sunsite.dk>, Arne Vajh�j
> <ar...@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 <ar...@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).
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.
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.
> Usually, the customer just wants the project finished, and never mind
> about the format of the code.
:-)
But after 20 years with high annual maintenance cost it also happens
that they regret.
Arne
Message has been deleted
lipska the kat
May 14, 2013, 4:26:24 AM5/14/13
to
On 14/05/13 01:44, Lew wrote:
> Jim Gibson wrote:
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?
> 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
>>> 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?
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?
Daniele Futtorovic
May 14, 2013, 7:07:22 AM5/14/13
to
On 14/05/2013 03:16, Stefan Ram allegedly wrote:
> 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.
> Jim Gibson <jimsg...@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
>> To my limited knowledge Java is the only language whose originating
>> vendor publishes an "official" formatting standard.
>
> 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.
Jim Gibson
May 14, 2013, 1:23:53 PM5/14/13
to
In article <b0291da6-a9ad-4848...@googlegroups.com>, Lew
<lewb...@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
<lewb...@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.
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.
> 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!
"sociopathic". Just works for me.
--
Jim Gibson
Roedy Green
May 15, 2013, 6:43:36 AM5/15/13
to
On 7 May 2013 14:23:50 GMT, r...@zedat.fu-berlin.de (Stefan Ram) wrote,
quoted or indirectly quoted someone who said :
> There are several different ways to format texts with braces
> and parentheses. One of them is being described here.
This was the sort of thing that blew teams apart in the old days.
Today we have beautifiers so you can format it to you personal
preference, then put it back to corporate standard and commit to
Subversion.
Logically Java snippets in newsgroups should be logically separate
from the message body so that the viewer can automatically reformat
them.
--
Roedy Green Canadian Mind Products http://mindprod.com
Nothing is so good as it seems beforehand.
~ George Eliot (born: 1819-11-22 died: 1880-12-22 at age: 61) (Mary Ann Evans)
quoted or indirectly quoted someone who said :
> There are several different ways to format texts with braces
> and parentheses. One of them is being described here.
This was the sort of thing that blew teams apart in the old days.
Today we have beautifiers so you can format it to you personal
preference, then put it back to corporate standard and commit to
Subversion.
Logically Java snippets in newsgroups should be logically separate
from the message body so that the viewer can automatically reformat
them.
--
Roedy Green Canadian Mind Products http://mindprod.com
Nothing is so good as it seems beforehand.
~ George Eliot (born: 1819-11-22 died: 1880-12-22 at age: 61) (Mary Ann Evans)
Arved Sandstrom
May 15, 2013, 5:47:07 PM5/15/13
to
On 05/14/2013 08:07 AM, Daniele Futtorovic wrote:
> On 14/05/2013 03:16, Stefan Ram allegedly wrote:
>> Jim Gibson <jimsg...@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
> On 14/05/2013 03:16, Stefan Ram allegedly wrote:
>> Jim Gibson <jimsg...@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?
of a math package I would not.
AHS
Daniele Futtorovic
May 15, 2013, 11:28:51 PM5/15/13
to
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.
Arved Sandstrom
May 17, 2013, 6:44:50 PM5/17/13
to
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
Arne Vajhøj
May 17, 2013, 7:42:14 PM5/17/13
to
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?
> Even if the language, such as C, doesn't have an official standard but it does have a de
> facto standard,
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.
> Just use the
> standard format,
Arne
Arne Vajhøj
May 17, 2013, 7:43:40 PM5/17/13
to
On 5/14/2013 1:23 PM, Jim Gibson wrote:
> In article <b0291da6-a9ad-4848...@googlegroups.com>, Lew
> <lewb...@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.
> In article <b0291da6-a9ad-4848...@googlegroups.com>, Lew
> <lewb...@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.
Arne
Stanimir Stamenkov
May 26, 2013, 1:35:40 PM5/26/13
to
14 May 2013 01:16:41 GMT, /Stefan Ram/:
> »By convention, method names should be a verb in
<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
> »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
> 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 ))
<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
0 new messages