«

Alex Hunsley wrote:

> 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

Lew wrote:

> Style is [...]

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

-- chris

On Feb 5, 10:25 pm, Lew <con...@nospam.lewscanon.com> wrote:
> "Amali" wrote:
> >> What is meant by programming "style" and why it is important
> Hak...@gmail.com wrote:
> > 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


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);

On Feb 6, 9:27 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:
> Lew wrote:
> > Style is [...]
>
> Nah, true style is setting your editor to use green against a black
> background...
>
> -- chris

I always prefered Amber on black

Daniel Pitts wrote:
> 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

Daniel Pitts wrote:

>
> 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.everyoneLookSeriousAndProfessionalAndUtter lyDedicatedToThePointOfBeingPaperThinCharacterisat ionsOfOneDimensionalCartoonCharacters();

..ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
http://www.EdmundKirwan.com/servlet/...c-page130.html

> On Feb 5, 1:12 pm, "Amali" <amalikarunanay...@gmail.com> wrote:
> What is meant by programming "style" and why it is important

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

>> Why have code conventions? Code conventions are important to
>> programmers for a number of reasons:
>>
>> * 80% of the lifetime cost of a piece of software goes to maintenance.
>> * Hardly any software is maintained for its whole life by the original author.
>> * Code conventions improve the readability of the software, allowing
>> engineers to understand new code more quickly and thoroughly.