Prev: sync vs async webservices
Next: Display image selected from JFileChooser
From: Mike Barnard on 12 Jun 2010 04:30
On Fri, 11 Jun 2010 23:22:16 -0400, Lew <noone(a)lewscanon.com> wrote:

>Mike Barnard wrote:
>> Wow, that was quick. I hope your time zones are a bit more friendly
>> than mine! It's half past midnight here.
>
>Ah, Summer Time! What we Yanks call "Daylight Savings Time", which causes
>pedants to remind us that technically it's called "Daylight Saving Time".
>
>It's the level of nitpickiness that is relevant. We humans get away with
>"Daylight Savings Time" or "system.out"; when we make that kind of mistake in
>source code all heck breaks loose.
>
>Arne Vajh�j wrote:
>>> Java is case sensitive.
>
>Mike Barnard wrote:
>> Thank you. Lesson one. Examine each character of code for Case! I
>> shall get onto it.
>
>There's more, when you're ready. By convention, Java case is not arbitrary,
>though the language /per se/ largely permits it to be. You are free in theory
>to name a class 'myclass' and a do-something method 'do_something()', but in
>practice you'll make every professional Java programmer cringe. Few will be
>polite enough not to tell you so.
>
>Nor should they be.
>
>People largely follow the Sun Java Coding Conventions
><http://java.sun.com/docs/codeconv/index.html>
>There's some wiggle. People will tolerate either brace-placement variant, and
>other varying allowances of style, but the basic naming rules are:
>
>Use camel case - make compound words with each word part (except maybe the
>first) capitalized, as in 'PileDriver' or 'makeSomethingHappen()'. Go ahead,
>spell things out - cut-and-paste will save you back the few microergs of extra
>typing energy that meaningful, unabbreviated names cost.
>
>Type names (interfaces and classes) begin with an upper-case letter. You
>don't need to put "Interface" or "Class" into the names, just the name of the
>type or implementation itself. Example: 'List' and 'ArrayList', an interface
>and a concrete implementation of that interface. Interfaces tend to name a
>quality, like 'Serializable', 'Iterable'. They often have single-word names,
>'Queue', sometimes double, like 'ResultSet'. Class names tend to show more
>concreteness:
> 'PriorityBlockingQueue<E> implements Queue<E>, Iterable<E>, ...'
>
>Method and variable names begin with a lower-case letter.
> private int degree;
> public int size();
> public int remainingCapacity();
>
>You don't use underscores.
>
>With a major exception - constant variables.
>
>A constant variables is either an enum value name or a variable that doesn't
>change because it's 'final' and obeys certain compile-time rules of constancy.
> People think loosely of other kinds of final variable as "constants" also.
>
>You convey constancy by spelling the name in all upper-case, using underscores
>to separate word parts instead of camel case.
>
> protected static final int STANDARD_DEGREE = 17;
> public static final String MODULE_NAME = "Soyuz 17";
> private final Status BIRTH_STATUS = Status.INNOCENT;
>
>Now it's easy to remember that 'System', a class, begins with upper case, and
>'out', a static variable, with lower case, thus 'System.out'.
>
>'print()', an instance method, begins with lower case, thus
>'System.out.print(something)'

Thanks for the heads up on this. I already have a link to a web page
explaining conventions but the more it's rammed down my throat the
better.

From: Lew on 12 Jun 2010 09:13
Mike Barnard wrote:
> Thanks for the heads up on this. I already have a link to a web page
> explaining conventions but the more it's rammed down my throat the
> better.

The link had better be
<http://java.sun.com/docs/codeconv/index.html>

Anything else for Java coding conventions is either a rehash of that or
expresses a private convention.

As for the conventions, remember that there's wiggle room.

A substantial contingent puts opening braces under the control statement,
method declaration or whatever, not on the same line, thus

public void doSomething( Foo arg )
{
if ( arg == null )
{
final String msg = "Null arg";
logger.error( msg );
throw new IllegalArgumentException( msg );
}
...

as opposed to

public void doSomething( Foo arg ) {
if ( arg == null ) {
final String msg = "Null arg";
logger.error( msg );
throw new IllegalArgumentException( msg );
}
...

Both styles are generally recognized, though the discussion of which is better
is on the order of the religious wars fought over transubstantiation vs.
consubstantiation, with burning at the stake being figurative rather than literal.

Just so you know, putting the opening brace on its own line is the One True
Way, and those who follow the "on-the-same-line" dogma of the official
convention are the heretics. Smiley-face. (Too many humorless fuddy-duddies
who read this forum might miss the ironic humor in my claim, so: SMILEY-FACE!
Get it? SMILEY-FACE! Even though it's only the simple truth -
opening-brace on its own line is clearly the superior style. Just don't
indent the braces differently from their controlling line.)

Also in wiggle room - spelling a non-constant 'final' variable with all upper
case and underscores. This is defensible if the object it points to is immutable.

Also in wiggle room - the exact amount to indent nested levels. Up to eight
spaces is cool for real code, but four is better and is the maximum for Usenet
posts. Don't use TABs to indent.

Also in wiggle room, but less so - package names should be all lower case,
with no underscores. You can sometimes get away with an upper-case letter.

Also in wiggle room - using your domain or a fake domain to derive package
names. Code for the "foo" project from "lewscanon.com" should have the domain
reversed as the package namespace prefix, thus "com.lewscanon.foo",
"com.lewscanon.foo.utility", etc. You can certainly use other prefixes.

--
Lew
First  |  Prev  | 
Pages: 1 2
Prev: sync vs async webservices
Next: Display image selected from JFileChooser