programming styles

[Amali]

What is meant by programming "style" and why it is important

 

[Alex Hunsley]

What is meant by programming "style" and why it is important

What is meant by homework, and why is it important not to cheat at it?

 

[Liz]

What is meant by programming "style" and why it is important

Observing naming conventions.
One statement per line.
Using appropriate comments.
Indenting code to show structure.
Avoiding obfuscation.

Those are important.

There might be more subtle elements of "style", such as the order in
which you put a gui together, which might be important to an
individual programmer because by following their own routine they
ensure that everything is covered.

 

[Hakusa]

What is meant by programming "style" and why it is important

It's important because it makes your code more readable.
Some conventions like where to put the brackets might seem odd to you,
but if everyone puts them in similar places, it's easier to read
everyones code.

Many people have died over long winded discussions of format, spacing
and such.

 

[John T]

Avoiding obfuscation.

I have run into this word many times and am unclear as to how one of
these definitions:

1. to confuse, bewilder, or stupefy.
2. to make obscure or unclear: to obfuscate a problem with extraneous
information.
3. to darken.

relates to Java programming. Is there a definition which is more
applicable to Java or is the general "make it hard to understand"
concise enough?

 

[Lew]

It's important because it makes your code more readable.
Some conventions like where to put the brackets might seem odd to you,
but if everyone puts them in similar places, it's easier to read
everyones code.

Many people have died over long winded discussions of format, spacing
and such.

There is far more to style than mere indentation. Where you place your braces
isn't style, it's formatting. Style is whether you use compact algorithms with
solid invariants and good error checking, or if you just slap together some
crude loops and hope it works. Style is anally javadocing everything in sight,
vs. letting the next schnook forensically discern your intentions. Style is
choosing whether to make a method public final or protected inheritable. Style
is making nicely encapsulated, beautifully cooperating modules that emergently
produce magic and cannot break or fail in the face of the most outrageous user
input. Style is coding an application at sixty-four times the industry average
and having a fraction of the bugs, and leaving easy room for every future
enhancement the customer wishes.

As long as you remain focused on the braces and indents, you will never see
the grasshopper.

- Lew

 

[Luc The Perverse]

I have run into this word many times and am unclear as to how one of these
definitions:

1. to confuse, bewilder, or stupefy.
2. to make obscure or unclear: to obfuscate a problem with extraneous
information.
3. to darken.

relates to Java programming. Is there a definition which is more
applicable to Java or is the general "make it hard to understand" concise
enough?

Deliberate obfuscation is doing "tricks" to make your code exceptionally
hard to understand.

Simple examples are since the letter l (lowercase) looks like the number 1,
you could have some obscure reference int l = 200

and then have a for statement

for(int x=l;x<201;x++)


Which appears to run 200 times (if you don't realize the l is an L not the
number 1) but really only runs once

Another is exceptionally unusual names for functions and variables (most
effective when they have NOTHING to do with what the variable actually
does/means)

while(EaT(DOG + cat) - BuNNy > S142 )

etc.

Though not java for an extreme case of c code obfuscation look no further
than the international c obfuscation contest!

http://www.ioccc.org/2004/anonymous.c Here is an example winning entry.

Java is a little harder to obfuscate than c or c++ because there are no
macros.

 

[dagarwal82]

Amail... worte:-

What is meant by programming "style" and why it is important

/* why it is important */
Just make a big hall or a room at your home and keep everything in
that messed up.
Now everyday when you need something ,go to the hall and find the
things..... (It may include your hair-brush, tooth-paste, tooth-
brush... a lot of things)....

/* What is meant by programming "style" */
Now, keep your tooth-paste and tooth-brush near wash-basin, hairbrush
and makeup on the dressing table. This is what a programming style
mean. Right thing at the right place at the right time.

 

[Alex Hunsley]

I have run into this word many times and am unclear as to how one of
these definitions:

1. to confuse, bewilder, or stupefy.
2. to make obscure or unclear: to obfuscate a problem with extraneous
information.
3. to darken.

relates to Java programming. Is there a definition which is more
applicable to Java or is the general "make it hard to understand"
concise enough?

Btw, there are broadly two types:
1) source code level obfuscation, which is what the others are talking about
2) bytecode obfuscation - compacts the bytecode (also in the process
making it probably harder to pick meaning out of any decompilation of
said bytecode) - often used in J2ME projects to reduce download size

 

[Chris Uppal]

John T wrote:

[about "obfuctation"]

Is there a definition which is more
applicable to Java or is the general "make it hard to understand"
concise enough?

That's pretty close. The term gains a couple of small extra shades of meaning
in a Java context, though.

One shade is inherited from more general programming terminology, where
"obfuscate" tends to suggest a /deliberate/ (wilful, playful, or malicious)
attempt to obscure the meaning of some bit of code.

Another shade comes from the fact that Java is translated into, and delivered
as, rather easy-to-understand bytecode. So some people see a need for
"obfuscators" which mangle that bytecode in an attempt to hide its meaning and
structure from those who might seek to discover it.

-- chris

 

[Chris Uppal]

2) bytecode obfuscation - compacts the bytecode (also in the process
making it probably harder to pick meaning out of any decompilation of
said bytecode) - often used in J2ME projects to reduce download size

Technically, compaction and obfuscation are separate operations. Although it's
true that some compaction techniques (such as shrinking and overloading
identifiers) do have a definite obfuscating effect. And although more
obfuscators can do some compaction too, there are other obfuscation techniques
(such as control flow rearrangement) which don't necessarily shrink the
bytecode. Indeed I can't see any reason why an obfuscator might not
deliberately bloat the bytecode (for instance introducing artificial code
blocks which jump to some instruction, thus making it harder to analyse the
purpose of the target code).

-- chris

 

[Chris Uppal]

Style is [...]

Nah, true style is setting your editor to use green against a black
background...

-- chris

 

[Daniel Pitts]

There is far more to style than mere indentation. Where you place your braces
isn't style, it's formatting. Style is whether you use compact algorithms with
solid invariants and good error checking, or if you just slap together some
crude loops and hope it works. Style is anally javadocing everything in sight,
vs. letting the next schnook forensically discern your intentions. Style is
choosing whether to make a method public final or protected inheritable. Style
is making nicely encapsulated, beautifully cooperating modules that emergently
produce magic and cannot break or fail in the face of the most outrageous user
input. Style is coding an application at sixty-four times the industry average
and having a fraction of the bugs, and leaving easy room for every future
enhancement the customer wishes.

As long as you remain focused on the braces and indents, you will never see
the grasshopper.

- Lew

Or, using javadoc to bury the smell of bad naming conventions.

Which would you rather see, the javadoc version?
// Ask the scenes forensic-material-team to scout the scene.
fmt().go(s)
--- or the self-documenting version?
getForensicMeterialTeam().scout(scene);

 

[Daniel Pitts]

Style is [...]

Nah, true style is setting your editor to use green against a black
background...

-- chris

I always prefered Amber on black

 

[Lew]

Or, using javadoc to bury the smell of bad naming conventions.

Which would you rather see, the javadoc version?
// Ask the scenes forensic-material-team to scout the scene.
fmt().go(s)
--- or the self-documenting version?
getForensicMeterialTeam().scout(scene);

Both.

Javadocs are for more than just source-code reading; they provide an API
reference. They should at least describe the guzintas and comzouttas and
checked exceptions, and often include special information, such as the
algorithmic complexity of a particular implementation (cf. the Javadocs for
different Collection classes).

For source readability, names should be chosen to be clear without excessive
redundancy. The example "getForensicMeterialTeam().scout(scene)" shows good
nomenclature policy. Such "self-documenting" names should work synergistically
with the Javadocs to aid maintainability and utility of the code.

A "bad" name is something like your example of "fmt().go(s)" (too terse), and
names like "userNameString" (the "String" portion is at least redundant and
potentially misleading) or "aNameThatIsReallyFarTooLongToBeUseful".

- Lew

 

[Ed Kirwan]

Or, using javadoc to bury the smell of bad naming conventions.

Which would you rather see, the javadoc version?
// Ask the scenes forensic-material-team to scout the scene.
fmt().go(s)
--- or the self-documenting version?
getForensicMeterialTeam().scout(scene);

What will your javadoc for the getForensicMeterialTeam() method look like?

Perhaps,

/**
* Returns the forensic materials team relevant to the current
* investigation.
*
* @return team responsible for investigating materials at the
* behest of a judiciary
*/

The point being, it's lovely to have getForensicMeterialTeam() in your
code, instead of the alternative above, but you won't get rid of the
comment: you'll just move it (to a more appropriate place).

And the code will no-doubt continue:
CSITeam csiTeam = getCSITeam();
csiTeam.everyoneLookSeriousAndProfessionalAndUtterlyDedicatedToThePointOfBeingPaperThinCharacterisationsOfOneDimensionalCartoonCharacters();

..ed

 

[MikeNereson]

What is meant by programming "style" and why it is important

Sun, at http://java.sun.com/docs/codeconv/ states