 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2007programming styles
What is meant by programming "style" and why it is important > 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? >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. > 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? >> Avoiding obfuscation. > I have run into this word many times and am unclear as to how one of these [quoted text clipped - 8 lines] > 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.  SignatureLTP How can you have any pudding if you don't eat your meat? 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. >> Avoiding obfuscation. > I have run into this word many times and am unclear as to how one of [quoted text clipped - 8 lines] > 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 > 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 [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 > 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. "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, [quoted text clipped - 3 lines] > 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 > Style is [...] Nah, true style is setting your editor to use green against a black background... -- chris On Feb 6, 9:27 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE- THIS.org> wrote: > > Style is [...] > > Nah, true style is setting your editor to use green against a black > background... > > -- chris I always prefered Amber on black :-) > "Amali" wrote: > >> What is meant by programming "style" and why it is important [quoted text clipped - 23 lines] > > - 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); > Or, using javadoc to bury the smell of bad naming conventions. > [quoted text clipped - 3 lines] > --- 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 > Or, using javadoc to bury the smell of bad naming conventions. > [quoted text clipped - 3 lines] > --- 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 Signaturewww.EdmundKirwan.com - Home of The Fractal Class Composition. Download Fractality, free Java code analyzer: www.EdmundKirwan.com/servlet/fractal/frac-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: [quoted text clipped - 3 lines] >> * Code conventions improve the readability of the software, allowing >> engineers to understand new code more quickly and thoroughly. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.