programming styles

Discussion in 'Java' started by Amali, Feb 5, 2007.

  1. Amali

    Amali Guest

    What is meant by programming "style" and why it is important
     
    Amali, Feb 5, 2007
    #1
    1. Advertising

  2. Amali

    Alex Hunsley Guest

    Amali wrote:
    > 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?
     
    Alex Hunsley, Feb 5, 2007
    #2
    1. Advertising

  3. Amali

    Liz Guest

    On 5 Feb 2007 10:12:05 -0800, Amali wrote:

    >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.
     
    Liz, Feb 5, 2007
    #3
  4. Amali

    Guest

    On Feb 5, 1:12 pm, "Amali" <> wrote:
    > 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.
     
    , Feb 5, 2007
    #4
  5. Amali

    John T Guest

    Liz wrote:
    > 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?
     
    John T, Feb 5, 2007
    #5
  6. Amali

    Lew Guest

    "Amali" wrote:
    >> What is meant by programming "style" and why it is important


    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
     
    Lew, Feb 6, 2007
    #6
  7. "John T" <> wrote in message
    news:knPxh.2964$...
    > Liz wrote:
    >> 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?


    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.

    --
    LTP

    How can you have any pudding if you don't eat your meat?
     
    Luc The Perverse, Feb 6, 2007
    #7
  8. Amali

    Guest

    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.
     
    , Feb 6, 2007
    #8
  9. Amali

    Alex Hunsley Guest

    John T wrote:
    > Liz wrote:
    >> 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?


    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
     
    Alex Hunsley, Feb 6, 2007
    #9
  10. Amali

    Chris Uppal Guest

    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, Feb 6, 2007
    #10
  11. Amali

    Chris Uppal Guest

    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
     
    Chris Uppal, Feb 6, 2007
    #11
  12. Amali

    Chris Uppal Guest

    Lew wrote:

    > Style is [...]


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

    -- chris
     
    Chris Uppal, Feb 6, 2007
    #12
  13. Amali

    Daniel Pitts Guest

    On Feb 5, 10:25 pm, Lew <> wrote:
    > "Amali" wrote:
    > >> What is meant by programming "style" and why it is important

    > 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);
     
    Daniel Pitts, Feb 6, 2007
    #13
  14. Amali

    Daniel Pitts Guest

    On Feb 6, 9:27 am, "Chris Uppal" <-
    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, Feb 6, 2007
    #14
  15. Amali

    Lew Guest

    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
     
    Lew, Feb 7, 2007
    #15
  16. Amali

    Ed Kirwan Guest

    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.everyoneLookSeriousAndProfessionalAndUtterlyDedicatedToThePointOfBeingPaperThinCharacterisationsOfOneDimensionalCartoonCharacters();

    ..ed

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

    Download Fractality, free Java code analyzer:
    www.EdmundKirwan.com/servlet/fractal/frac-page130.html
     
    Ed Kirwan, Feb 7, 2007
    #16
  17. Amali

    MikeNereson Guest

    > On Feb 5, 1:12 pm, "Amali" <> 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.
     
    MikeNereson, Feb 7, 2007
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Phil S.

    Styles missing after upgrade

    Phil S., Jul 8, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    327
    Phil S.
    Jul 8, 2003
  2. Thomas Korsgaard

    Styles of programming

    Thomas Korsgaard, Dec 11, 2005, in forum: Java
    Replies:
    5
    Views:
    374
  3. Chris Mantoulidis

    (Programming) Various Syntax styles

    Chris Mantoulidis, Dec 11, 2003, in forum: C++
    Replies:
    18
    Views:
    686
    Nils Petter Vaskinn
    Dec 15, 2003
  4. Replies:
    3
    Views:
    268
    Michael Hoffman
    May 20, 2007
  5. Bill
    Replies:
    16
    Views:
    241
    David Ross
    Oct 17, 2004
Loading...

Share This Page