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

Groups > comp.lang.java.help > #2003 > unrolled thread

Why so many imports instead of java.io.* ?

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

Contents

  Why so many imports instead of java.io.* ? Timothy Madden <terminatorul@gmail.com> - 2012-08-14 15:23 +0300
    Re: Why so many imports instead of java.io.* ? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-14 08:45 -0400
      Re: Why so many imports instead of java.io.* ? Patricia Shanahan <pats@acm.org> - 2012-08-14 06:16 -0700
        Re: Why so many imports instead of java.io.* ? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-14 10:52 -0400
    Re: Why so many imports instead of java.io.* ? Jeff Higgins <jeff@invalid.invalid> - 2012-08-14 09:05 -0400
    Re: Why so many imports instead of java.io.* ? Lew <lewbloch@gmail.com> - 2012-08-14 16:31 -0700
      Re: Why so many imports instead of java.io.* ? Timothy Madden <terminatorul@gmail.com> - 2012-08-16 16:39 +0300
        Re: Why so many imports instead of java.io.* ? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-16 11:51 -0400
          Re: Why so many imports instead of java.io.* ? Timothy Madden <terminatorul@gmail.com> - 2012-08-17 15:08 +0300
            Re: Why so many imports instead of java.io.* ? Lew <lewbloch@gmail.com> - 2012-08-17 11:26 -0700
              Re: Why so many imports instead of java.io.* ? Gene Wirchenko <genew@ocis.net> - 2012-08-17 12:53 -0700
                Re: Why so many imports instead of java.io.* ? Lew <lewbloch@gmail.com> - 2012-08-17 12:58 -0700
                  Re: Why so many imports instead of java.io.* ? Gene Wirchenko <genew@ocis.net> - 2012-08-17 13:27 -0700
                    Re: Why so many imports instead of java.io.* ? Timothy Madden <terminatorul@gmail.com> - 2012-08-20 19:09 +0300
                      Re: Why so many imports instead of java.io.* ? Patricia Shanahan <pats@acm.org> - 2012-08-20 09:40 -0700
                        Re: Why so many imports instead of java.io.* ? Timothy Madden <terminatorul@gmail.com> - 2012-08-21 15:03 +0300
                          Re: Why so many imports instead of java.io.* ? Gene Wirchenko <genew@ocis.net> - 2012-08-21 09:05 -0700
                          Re: Why so many imports instead of java.io.* ? Patricia Shanahan <pats@acm.org> - 2012-08-21 09:48 -0700
                            Re: Why so many imports instead of java.io.* ? Lew <lewbloch@gmail.com> - 2012-08-21 11:51 -0700
                  Re: Why so many imports instead of java.io.* ? Patricia Shanahan <pats@acm.org> - 2012-08-17 14:39 -0700
                    Re: Why so many imports instead of java.io.* ? Lew <lewbloch@gmail.com> - 2012-08-17 15:39 -0700
                      Re: Why so many imports instead of java.io.* ? Gene Wirchenko <genew@ocis.net> - 2012-08-17 15:57 -0700
                        Re: Why so many imports instead of java.io.* ? Lew <noone@lewscanon.com> - 2012-08-18 11:03 -0700
                          Re: Why so many imports instead of java.io.* ? Gene Wirchenko <genew@ocis.net> - 2012-08-19 18:07 -0700
    Re: Why so many imports instead of java.io.* ? Roedy Green <see_website@mindprod.com.invalid> - 2012-08-14 17:46 -0700

Page 1 of 2  [1] 2  Next page →

#2003 — Why so many imports instead of java.io.* ?

Hello

Is it just me or people tend to enumerate all the needed classes for a
Java source file each in its own import line ?

Why is it better to use:
   import java.io.IOException
   import java.io.FileNotFoundException
   import java.io.FileOutputStream
   import ...
instead of just:
   import java.io.*
?

Which, by the way, also needs no maintenance in case a new class or
exception is needed in the file at a later time.

Thank you,
Timothy Madden

[toc] | [next] | [standalone]

#2004

On 8/14/2012 8:23 AM, Timothy Madden wrote:
> Hello
>
> Is it just me or people tend to enumerate all the needed classes for a
> Java source file each in its own import line ?
>
> Why is it better to use:
>     import java.io.IOException
>     import java.io.FileNotFoundException
>     import java.io.FileOutputStream
>     import ...
> instead of just:
>     import java.io.*
> ?
>
> Which, by the way, also needs no maintenance in case a new class or
> exception is needed in the file at a later time.

     On the other hand, it *will* need maintenance if the next
Java release adds a java.io.Wotsit class, and your file already
has its own Wotsit.  Import them one by one and the new Wotsit
won't clash with yours; import them en masse and it will.

     The rest of the answer, I think, is that Somebody Somewhere
decided that it was "better style" to import individually than
by wildcard, and SS' opinion got codified into the out-of-the-box
settings for tools like Eclipse and NetBeans.  Bowing to SS' ideas,
these tools complain about wildcard imports, while at the same time
making it easy to generate the individual imports.  Most people
don't tinker much with the out-of-the-box settings, so the code they
create with these IDE's follow that style.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#2006

On 8/14/2012 5:45 AM, Eric Sosman wrote:
> On 8/14/2012 8:23 AM, Timothy Madden wrote:
>> Hello
>>
>> Is it just me or people tend to enumerate all the needed classes for a
>> Java source file each in its own import line ?
>>
>> Why is it better to use:
>>     import java.io.IOException
>>     import java.io.FileNotFoundException
>>     import java.io.FileOutputStream
>>     import ...
>> instead of just:
>>     import java.io.*
>> ?
>>
>> Which, by the way, also needs no maintenance in case a new class or
>> exception is needed in the file at a later time.
>
>      On the other hand, it *will* need maintenance if the next
> Java release adds a java.io.Wotsit class, and your file already
> has its own Wotsit.  Import them one by one and the new Wotsit
> won't clash with yours; import them en masse and it will.
>
>      The rest of the answer, I think, is that Somebody Somewhere
> decided that it was "better style" to import individually than
> by wildcard, and SS' opinion got codified into the out-of-the-box
> settings for tools like Eclipse and NetBeans.  Bowing to SS' ideas,
> these tools complain about wildcard imports, while at the same time
> making it easy to generate the individual imports.  Most people
> don't tinker much with the out-of-the-box settings, so the code they
> create with these IDE's follow that style.
>

I don't think the out-of-box settings in e.g. Eclipse should drive
actual programming style. A programmer who prefers wildcard imports
should use them, and tell the IDE not to warn on it.

I would perhaps be too lazy to do single class imports without IDE support.

Personally, I prefer specific class imports because that way the imports
give a quick overview of the external features the class uses.

Patricia

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

#2007

On 8/14/2012 9:16 AM, Patricia Shanahan wrote:
> On 8/14/2012 5:45 AM, Eric Sosman wrote:
>> On 8/14/2012 8:23 AM, Timothy Madden wrote:
>>> Hello
>>>
>>> Is it just me or people tend to enumerate all the needed classes for a
>>> Java source file each in its own import line ?
>>>
>>> Why is it better to use:
>>>     import java.io.IOException
>>>     import java.io.FileNotFoundException
>>>     import java.io.FileOutputStream
>>>     import ...
>>> instead of just:
>>>     import java.io.*
>>> ?
>>>
>>> Which, by the way, also needs no maintenance in case a new class or
>>> exception is needed in the file at a later time.
>>
>>      On the other hand, it *will* need maintenance if the next
>> Java release adds a java.io.Wotsit class, and your file already
>> has its own Wotsit.  Import them one by one and the new Wotsit
>> won't clash with yours; import them en masse and it will.
>>
>>      The rest of the answer, I think, is that Somebody Somewhere
>> decided that it was "better style" to import individually than
>> by wildcard, and SS' opinion got codified into the out-of-the-box
>> settings for tools like Eclipse and NetBeans.  Bowing to SS' ideas,
>> these tools complain about wildcard imports, while at the same time
>> making it easy to generate the individual imports.  Most people
>> don't tinker much with the out-of-the-box settings, so the code they
>> create with these IDE's follow that style.
>>
>
> I don't think the out-of-box settings in e.g. Eclipse should drive
> actual programming style. A programmer who prefers wildcard imports
> should use them, and tell the IDE not to warn on it.

     Whether they "should" or not, I rather think they tend to.
You've got this IDE with about a jillion configurable behaviors,
and you only tweak those that are actual pain points.  If you
prefer wildcard imports strongly enough to spend the time finding
the proper knob you'll do so -- but if it doesn't bother you that
much you won't, and the default will win.

     Case in point: Me, the exemplar of lazy programmers.  Some
years ago NetBeans would use wildcards if you imported N or more
classes from the same package, individual imports for fewer.  At
the time, I spent the small effort to find where N was configured,
and adjusted the threshold a little.  But in recent NetBeans
versions that configuration has either vanished or moved somewhere
else, and guess what?  I haven't spent the time to try to find it,
but have simply gone with the flow and let NetBeans manage the
imports as it chooses.  It means that in some of my .java files you
need to scroll a fair way down before you find anything interesting,
which is a little irritating -- but not irritating enough to get me
to try to do something about it.

     (An ironic oddity: In NetBeans, if you refactor a class by moving
it from oldpackage to newpackage, NB adds `import oldpackage.*;' so
any oldpackage classes -- that used to be imported automatically
under the "same package" rule -- are still available in newpackage.
Then when you edit the refactored file, NB complains about the
wildcard import ...)

> I would perhaps be too lazy to do single class imports without IDE support.

     For me, you can delete the "perhaps."  Lacking IDE help, I'd
use wildcard imports all over the place to duck the effort of
staying up-to-date with every single class.  And I might get unlucky
when the java.io.Wotsit class appears next year ...

> Personally, I prefer specific class imports because that way the imports
> give a quick overview of the external features the class uses.

     When it's a shortish list, yes.  When you're writing Swing code,
you may find that the import list is so long as to be obfuscatory
rather than explanatory.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#2005

On 08/14/2012 08:23 AM, Timothy Madden wrote:
> Hello
>
> Is it just me or people tend to enumerate all the needed classes for a
> Java source file each in its own import line ?
>
I suspect it boils down to one of: "I want to.", I have to.", or "Huh?".

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

#2009

Timothy Madden wrote:
> Is it just me or people tend to enumerate all the needed classes for a
> Java source file each in its own import line ?

There is a strong indication that import-on-demand is not as good a 
practice as single-type imports.

<http://javadude.com/articles/importondemandisevil.html>
<http://www.javabestpractice.com/java/disadvantage-of-using-wildcards-in-java-import-statements.html>

"Using single-type imports is quite useful and an absolute requirement in the open source community as this code is usually really reviewed. Using single-type imports makes it easy for the code reader to quickly find out the package a particular type is in: You just search for the type name from the start of the source file."
<http://jalopy.sourceforge.net/existing/imports.html>

For arguments on both sides:
<http://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad>

And in general, why not do a search yourself across the InterWebz?
<http://lmgtfy.com/?q=java+import+on+demand+vs.+single-type+import>

> Why is it better to use: 
>    import java.io.IOException
>    import java.io.FileNotFoundException
>    import java.io.FileOutputStream
>    import ...
> 
> instead of just:
>    import java.io.*
> ?

Less confusion, elimination of simple-name collisions, more explicit 
documentation of what types it uses.

> Which, by the way, also needs no maintenance in case a new class or
> exception is needed in the file at a later time.

Not true.

It will need maintenance if that type name conflicts with another.

You don't actually need any import directives in a program at all.

The maintenance required for single-type import is negligible and not 
worth avoiding.

-- 
Lew

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

#2016

On 08/15/2012 02:31 AM, Lew wrote:
> Timothy Madden wrote:
>> Is it just me or people tend to enumerate all the needed classes for a
>> Java source file each in its own import line ?
> 
> There is a strong indication that import-on-demand is not as good a 
> practice as single-type imports.
> 
> <http://javadude.com/articles/importondemandisevil.html>
> <http://www.javabestpractice.com/java/disadvantage-of-using-wildcards-in-java-import-statements.html>
> 
> "Using single-type imports is quite useful and an absolute requirement in the open source community as this code is usually really reviewed. Using single-type imports makes it easy for the code reader to quickly find out the package a particular type is in: You just search for the type name from the start of the source file."
> <http://jalopy.sourceforge.net/existing/imports.html>
> 
> For arguments on both sides:
> <http://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad>
> 
> And in general, why not do a search yourself across the InterWebz?
> <http://lmgtfy.com/?q=java+import+on+demand+vs.+single-type+import>
> 
>> Why is it better to use: 
>>    import java.io.IOException
>>    import java.io.FileNotFoundException
>>    import java.io.FileOutputStream
>>    import ...
>>
>> instead of just:
>>    import java.io.*
>> ?
> 
> Less confusion, elimination of simple-name collisions, more explicit 
> documentation of what types it uses.
> 
>> Which, by the way, also needs no maintenance in case a new class or
>> exception is needed in the file at a later time.
> 
> Not true.
> 
> It will need maintenance if that type name conflicts with another.
> 
> You don't actually need any import directives in a program at all.
> 
> The maintenance required for single-type import is negligible and not 
> worth avoiding.

Thank you,
After reading the links (one of wich is currently broken) I see that
import lists are a work-around for a language-design problem...

Though I still find import-list a problem for /all/ Java-language
programmers in the world (which is only made a little easier by proper
IDEs), I agree with the them now. They should be used for future
compatibility between your code and the Java run-time classes.

I guess this issue has been a minus for Sun/Oracle since JDK 1.2 onwards.

Timothy Madden

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

#2019

On 8/16/2012 9:39 AM, Timothy Madden wrote:
>[...]
> After reading the links (one of wich is currently broken) I see that
> import lists are a work-around for a language-design problem...

     Not sure what "problem" you think they work around.  The
import directive is a convenience, nothing more: It allows you
to abbreviate java.io.BufferedReader as just BufferedReader,
but that's all.

     Off-hand, I can't think of a language that has namespaces
or namespace-like things that doesn't also have some way to
allow abbreviations of this kind.  If there is such a language,
I bet it's verbose.  Remember the Monty Python skit in which
an announcer speaks of the composer

	Johann Gambolputty de von Ausfern- schplenden- schlitter-
	crasscrenbon- fried- digger- dingle- dangle- dongle- dungle-
	burstein- von- knacker- thrasher- apple- banger- horowitz-
	ticolensic- grander- knotty- spelltinkle- grandlich-
	grumblemeyer- spelterwasser- kurstlich- himbleeisen-
	bahnwagen- gutenabend- bitte- ein- nürnburger- bratwustle-
	gerspurten- mitz- weimache- luber- hundsfut- gumberaber-
	shönedanker- kalbsfleisch- mittler- aucher von Hautkopft
	of Ulm

... and recites the entire thing at every mention?  Hey, Java
could have been like that!

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#2020

On 08/16/2012 06:51 PM, Eric Sosman wrote:
> On 8/16/2012 9:39 AM, Timothy Madden wrote:
>> [...]
>> After reading the links (one of wich is currently broken) I see that
>> import lists are a work-around for a language-design problem...
> 
>     Not sure what "problem" you think they work around.  The
> import directive is a convenience, nothing more: It allows you
> to abbreviate java.io.BufferedReader as just BufferedReader,
> but that's all.
> 
>     Off-hand, I can't think of a language that has namespaces
> or namespace-like things that doesn't also have some way to
> allow abbreviations of this kind.  If there is such a language,
> I bet it's verbose.

I see what you mean. A simple test shows that the same problem exists
with C++ namespaces and its using directive.

FreePascal documentation also says that a duplicate identifier is
imported from the unit last specified in the uses clause. I think this
approach produces the same problem as the open imports from Java (or
C++), and even worse ones.

Python is a little smarter: even after import, you still have to use the
qualified name. Or you can import the qualified name explicitly, than
you can use the simple name.

I also tried perl, but I am not good with it. Perl modules look like
they need explicit exports inside the module, if the import directive is
to import anything other than the module name. And these explicit
exports are scarce. All other module symbols need to be accessed as
qualified names, like in python, so it's still good.

I believe Ruby also exhibits no such "import of an open namespace"
problem. At least not directly, because in Ruby a module can serve as a
base class for a derived one, which is also a form of importing (and
extending) an existing namespace. But that is a different problem,
related to OOP, and which does not produce conflicts the same way
imports do.

So I see some languages have this problem when trying to import an "open
namespace", while other languages do not allow the "open namespace" to
be imported directly.

Maybe what Java needs is some new syntax like:
	import com.oracle.multiprocessing.* into mp;
and than any function f() from com.oracle.multiprocessing can only be
refferred to as mp.f();

P.S. Python wins (and it rocks, too) !

Thank you,
Timothy Madden

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

#2021

Timothy Madden wrote:
> P.S. Python wins (and it rocks, too) !

Language War!

It's futile to do Language War with Java partisans because we agree 
with the criticisms of the language, and respond with, "Y'think *that's* 
bad? What about <insert favorite Java feature to deprecate here>?"

It's what keeps Java vibrant - its community complains more about it 
than its opposition, and its fanboys engage in the opposite of the sort 
of religiously fervent proselytizing that distinguishes the fanboys of 
other computer languages.

-- 
Lew

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

#2022

On Fri, 17 Aug 2012 11:26:14 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

>Timothy Madden wrote:
>> P.S. Python wins (and it rocks, too) !
>
>Language War!
>
>It's futile to do Language War with Java partisans because we agree 
>with the criticisms of the language, and respond with, "Y'think *that's* 
>bad? What about <insert favorite Java feature to deprecate here>?"
>
>It's what keeps Java vibrant - its community complains more about it 
>than its opposition, and its fanboys engage in the opposite of the sort 
>of religiously fervent proselytizing that distinguishes the fanboys of 
>other computer languages.

     But you save it for the formatting and variable naming
conventions.

Sincerely,

Gene Wirchenko

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

#2023

Gene Wirchenko wrote:
>  Lew wrote:
>>Timothy Madden wrote:
>>> P.S. Python wins (and it rocks, too) !

>>Language War!
>>
>>It's futile to do Language War with Java partisans because we agree 
>>with the criticisms of the language, and respond with, "Y'think *that's* 
>>bad? What about <insert favorite Java feature to deprecate here>?"
>>
>>It's what keeps Java vibrant - its community complains more about it 
>>than its opposition, and its fanboys engage in the opposite of the sort 
>>of religiously fervent proselytizing that distinguishes the fanboys of 
>>other computer languages.

>      But you save it for the formatting and variable naming
> conventions.

I don't understand your remark. I can't recall having complained against 
the Java code conventions. What are you attempting to communicate there, 
Gene?

-- 
Lew

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

#2024

On Fri, 17 Aug 2012 12:58:18 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

>Gene Wirchenko wrote:
>>  Lew wrote:
>>>Timothy Madden wrote:
>>>> P.S. Python wins (and it rocks, too) !
>
>>>Language War!
>>>
>>>It's futile to do Language War with Java partisans because we agree 
>>>with the criticisms of the language, and respond with, "Y'think *that's* 
>>>bad? What about <insert favorite Java feature to deprecate here>?"
>>>
>>>It's what keeps Java vibrant - its community complains more about it 
>>>than its opposition, and its fanboys engage in the opposite of the sort 
>>>of religiously fervent proselytizing that distinguishes the fanboys of 
>>>other computer languages.
>
>>      But you save it for the formatting and variable naming
>> conventions.
>
>I don't understand your remark. I can't recall having complained against 
>the Java code conventions. What are you attempting to communicate there, 
>Gene?

     Lew, that is rather disingenuous of you.  Whenever anyone uses a
different convention, they get put down and rather harshly.  It is
quite fanatic what is done.

Sincerely,

Gene Wirchenko

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

#2040

On 08/17/2012 11:27 PM, Gene Wirchenko wrote:
> On Fri, 17 Aug 2012 12:58:18 -0700 (PDT), Lew <lewbloch@gmail.com>
> wrote:
> 
>> Gene Wirchenko wrote:
>>>  Lew wrote:
>>>> Timothy Madden wrote:
>>>>> P.S. Python wins (and it rocks, too) !
>>
>>>> Language War!
>>>>
>>>> It's futile to do Language War with Java partisans because we agree 
>>>> with the criticisms of the language, and respond with, "Y'think *that's* 
>>>> bad? What about <insert favorite Java feature to deprecate here>?"
>>>>
>>>> It's what keeps Java vibrant - its community complains more about it 
>>>> than its opposition, and its fanboys engage in the opposite of the sort 
>>>> of religiously fervent proselytizing that distinguishes the fanboys of 
>>>> other computer languages.
>>
>>>      But you save it for the formatting and variable naming
>>> conventions.
>>
>> I don't understand your remark. I can't recall having complained against 
>> the Java code conventions. What are you attempting to communicate there, 
>> Gene?
> 
>      Lew, that is rather disingenuous of you.  Whenever anyone uses a
> different convention, they get put down and rather harshly.  It is
> quite fanatic what is done.

I don't appreciate coding conventions either. For once, they are
mischievously named "conventions", "style" or "guidelines", but if you
don't follow them, you can't work in project ... which makes them hard
rules, not conventions.

And second, they are all wrong and insufficiently justified, most of the
times they are set by what some project manager (who, by the way, does
not code) "thinks" that the conventions should be.

But still, it would be nice to convince everybody, especially those
ubiquitos IDEs, to use the right tab size (and some soft tab stop) some
day or another, instead of the size that "seems" convenient.

Unfortunately most editors/IDEs do not understand that the size of a
hard tab is not really an user option, as it is set in hardware like
printers and consoles, or are hard-coded in system (read: poor) editors
that do not have configuration options for tab size. Make a test and try
to `cut`, `grep` or `type` a short file with tabs in a console window,
and see what the tab size actually is. Or try to send a text file
directly to a prinder.

Instead, editors and IDEs that want a "tab size" option should mainly
provide a soft tab stop, which means an user presses Tab to get an
indent, but does not necessarily get a hard tab (a tab character) in the
file at that place.

Sadly, untill the day comes that people understand this, we are forced
to use "replace tabs with spaces" ...

Thank you,
Timothy Madden

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

#2041

On 8/20/2012 9:09 AM, Timothy Madden wrote:
...
> I don't appreciate coding conventions either. For once, they are
> mischievously named "conventions", "style" or "guidelines", but if you
> don't follow them, you can't work in project ... which makes them hard
> rules, not conventions.

I do think a project should have rules, not conventions. I don't care
much what they are, as long as visible indent reflects logical nesting.

When I'm modifying existing code one of my objectives is to fit my
changes in smoothly, so that they don't break the thread for someone
reading the code. That means, among other things, following the same
style as the surrounding code.

If code within a project is formatted according to the preferences of
the programmer who created each module, I would have to either manually
format, with the risk of indent mistakes, or change the IDE to suit each
module.

If the project has a set of rules defined from the start, I can just set
my IDE project style settings appropriately and edit any module in the
project.

Gene goes a stage further than I would personally, and maintains style
consistency between languages, which results in an unusual style for his
Java code.

Patricia

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

#2045

On 08/20/2012 07:40 PM, Patricia Shanahan wrote:
> On 8/20/2012 9:09 AM, Timothy Madden wrote:
> ...
>> I don't appreciate coding conventions either. For once, they are
>> mischievously named "conventions", "style" or "guidelines", but if you
>> don't follow them, you can't work in project ... which makes them hard
>> rules, not conventions.
> 
> I do think a project should have rules, not conventions. I don't care
> much what they are, as long as visible indent reflects logical nesting.

Some programmers already have a style that they feel comfortable working
with, that they are used with. For them the "project should have rules,
though I don't care what they are" attitude is not good enough. A
different style is too annoying and distracts you from your work, and
chances to get a project that enforces exactly your style are slim.

This is why these "conventions" should be choosen carefully and should
be limited to a minimum of rules like:
	"use either spaces or a tab size of 8, an indent of +4, and use
         braces on their own line",
and otherwise let the programmers be creative and flexible, instead of
showing them a long document full of rules.

Regards,
Timothy Madden

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

#2047

On Tue, 21 Aug 2012 15:03:42 +0300, Timothy Madden
<terminatorul@gmail.com> wrote:

>On 08/20/2012 07:40 PM, Patricia Shanahan wrote:
>> On 8/20/2012 9:09 AM, Timothy Madden wrote:
>> ...
>>> I don't appreciate coding conventions either. For once, they are
>>> mischievously named "conventions", "style" or "guidelines", but if you
>>> don't follow them, you can't work in project ... which makes them hard
>>> rules, not conventions.
>> 
>> I do think a project should have rules, not conventions. I don't care
>> much what they are, as long as visible indent reflects logical nesting.
>
>Some programmers already have a style that they feel comfortable working
>with, that they are used with. For them the "project should have rules,
>though I don't care what they are" attitude is not good enough. A
>different style is too annoying and distracts you from your work, and
>chances to get a project that enforces exactly your style are slim.
>
>This is why these "conventions" should be choosen carefully and should
>be limited to a minimum of rules like:
>	"use either spaces or a tab size of 8, an indent of +4, and use
>         braces on their own line",
>and otherwise let the programmers be creative and flexible, instead of
>showing them a long document full of rules.

     Naming conventions are very useful.

Sincerely,

Gene Wirchenko

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

#2048

On 8/21/2012 5:03 AM, Timothy Madden wrote:
> On 08/20/2012 07:40 PM, Patricia Shanahan wrote:
>> On 8/20/2012 9:09 AM, Timothy Madden wrote:
>> ...
>>> I don't appreciate coding conventions either. For once, they are
>>> mischievously named "conventions", "style" or "guidelines", but if you
>>> don't follow them, you can't work in project ... which makes them hard
>>> rules, not conventions.
>>
>> I do think a project should have rules, not conventions. I don't care
>> much what they are, as long as visible indent reflects logical nesting.
>
> Some programmers already have a style that they feel comfortable working
> with, that they are used with. For them the "project should have rules,
> though I don't care what they are" attitude is not good enough. A
> different style is too annoying and distracts you from your work, and
> chances to get a project that enforces exactly your style are slim.
>
> This is why these "conventions" should be choosen carefully and should
> be limited to a minimum of rules like:
> 	"use either spaces or a tab size of 8, an indent of +4, and use
>           braces on their own line",
> and otherwise let the programmers be creative and flexible, instead of
> showing them a long document full of rules.

In your ideal world, what would happen when Tom needs to change a class
that Harry wrote? They disagree about just about everything except
indentation.

Would the class end up with most identifiers following Harry's
preferences, but a couple following Tom's preferences? What if Tom finds
Harry's style annoying and distracting? Will Joe, who later needs to
study the class, have to cope with two conventions in the same file?

Patricia

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

#2050

Patricia Shanahan wrote:
> Timothy Madden wrote:
>> Patricia Shanahan wrote:
>>> Timothy Madden wrote:
> >> ...
> >>> I don't appreciate coding conventions either. For once, they are
> >>> mischievously named "conventions", "style" or "guidelines", but if you
> >>> don't follow them, you can't work in project ... which makes them hard
> >>> rules, not conventions.
> 
> >> I do think a project should have rules, not conventions. I don't care
> >> much what they are, as long as visible indent reflects logical nesting.
> 
> > Some programmers already have a style that they feel comfortable working
> > with, that they are used with. For them the "project should have rules,
> > though I don't care what they are" attitude is not good enough. A
> > different style is too annoying and distracts you from your work, and
> > chances to get a project that enforces exactly your style are slim.

That's why good programmers always adapt to the house style.

Just like good writers follow the house style of the publication wherein 
they publish their work.

> > This is why these "conventions" should be choosen carefully and should
\> > be limited to a minimum of rules like:
> 
>> 	"use either spaces or a tab size of 8, an indent of +4, and use
>>           braces on their own line",
>> and otherwise let the programmers be creative and flexible, instead of
>> showing them a long document full of rules.

In the case of Java, that ship sailed thirteen years ago.

There are standards. Live with them.

> In your ideal world, what would happen when Tom needs to change a class
> that Harry wrote? They disagree about just about everything except
> indentation.
> 
> Would the class end up with most identifiers following Harry's
> preferences, but a couple following Tom's preferences? What if Tom finds
> Harry's style annoying and distracting? Will Joe, who later needs to
> study the class, have to cope with two conventions in the same file?

"A foolish consistency is the hobgoblin of little minds". But not if it isn't 
foolish.

I worked one place that told us, "We have coding standards. You will hate 
them. That's all right, as long as you follow them."

-- 
Lew

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

#2025

On 8/17/2012 12:58 PM, Lew wrote:
> Gene Wirchenko wrote:
>>   Lew wrote:
>>> Timothy Madden wrote:
>>>> P.S. Python wins (and it rocks, too) !
>
>>> Language War!
>>>
>>> It's futile to do Language War with Java partisans because we agree
>>> with the criticisms of the language, and respond with, "Y'think *that's*
>>> bad? What about <insert favorite Java feature to deprecate here>?"
>>>
>>> It's what keeps Java vibrant - its community complains more about it
>>> than its opposition, and its fanboys engage in the opposite of the sort
>>> of religiously fervent proselytizing that distinguishes the fanboys of
>>> other computer languages.
>
>>       But you save it for the formatting and variable naming
>> conventions.
>
> I don't understand your remark. I can't recall having complained against
> the Java code conventions. What are you attempting to communicate there,
> Gene?
>

Your attempts to encourage universal use of one set of Java coding
conventions are sometimes difficult to distinguish from religiously
fervent proselytizing.

Patricia

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web