Unformatted text preview:

Style Rules I Style is important Everyone agrees that good style is important Everyone agrees on most of the essentials But some people have religious wars over style It s the subtle points that get people really upset Subtle points mostly aren t very important The essential points make a clear difference so these are the ones people can agree on Just like a lot of other things in life About the book This book is a team effort by many good programmers not just one person s opinions The rules have been widely distributed and commented upon The rules reflect widespread and accepted practices And no I don t agree with everything in the book Rule 1 Adhere to the style of the original Consistent style is very important Most times you will enter an ongoing project with established style rules Follow them even if you don t like them Don t try to establish better style rules It won t work anyway There may be reasons you don t know about If a project has mixed styles with no consistency you might try to get people to agree on one Rule 3 Do it right the first time You re working on a large project so you use good style but you need a tool to help you do one little job so you slap it together quickly Guess which program will be around longer and used by more people The broken window theory In inner cities some buildings are beautiful and clean while others are rotting hulks Why Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism one that very quickly turns a clean intact inhabited building into a smashed and abandoned derelict A broken window From The Pragmatic Programmer Don t leave broken windows bad designs wrong decisions or poor code unrepaired Fix each one as soon as it is discovered If there is insufficient time to fix it properly then board it up Perhaps you can comment out the offending code or display a Not Implemented message or substitute dummy data instead Take some action to prevent further damage and to show that you re on top of the situation Rule 5 Indent nested code Always indent statements that are nested inside under the control of another statement if itemCost bankBalance writeCheck itemCost bankBalance bankBalance itemCost while seconds 0 System out print seconds seconds seconds 1 Indenting particular statements Java has several kinds of statements and the book tells how to indent each The general form is usually like this controlling statement nested statements Sometimes I violate good style on these slides because I have to make it all fit How much should you indent If you indent too little the indentation is harder to see and doesn t help very much If you indent too much deeply nested code gets pushed too far to the right In general 2 to 4 spaces seems about right The book suggests 2 spaces BlueJ s default is 4 spaces Just pick a number and stay with it Rule 6 Break up long lines Scrolling a window horizontally is a pain When you print on standard paper long lines are either cut off or wrap in bad places I have long used a 72 character limit Some editors will show you a limit line The book provides good advice on how to break up long lines read it Rule 8 Don t use hard tabs Once upon a time you could depend on tab stops every eight character positions Today every editor has its own idea of where and how to set tab stops If you change editors your nice indentation gets ruined It s worse if you use both tabs and spaces I have learned this one the hard way Soft tabs Some editors the good ones will let you set a preference so that when you type a tab the editor automatically uses the right number of spaces instead This is what is called a soft tab BlueJ uses exclusively soft tabs as of 1 1 4 Use tabs all you like in BlueJ Remember that most editors don t do this automatically What about the rules I skipped Those rules are important too I m skipping around for a variety of reasons Rules 2 and 4 will make more sense later Rule 7 has too much detail to talk about right now but it s a good rule I ll try to talk about every rule in class This is a good book worth reading several times The End


View Full Document

Penn CIT 591 - Style Rules I

Documents in this Course
Stacks

Stacks

11 pages

Arrays

Arrays

30 pages

Arrays

Arrays

29 pages

Applets

Applets

24 pages

Style

Style

33 pages

JUnit

JUnit

23 pages

Java

Java

32 pages

Access

Access

18 pages

Methods

Methods

29 pages

Arrays

Arrays

32 pages

Methods

Methods

9 pages

Methods

Methods

29 pages

Vectors

Vectors

14 pages

Eclipse

Eclipse

23 pages

Vectors

Vectors

14 pages

Recursion

Recursion

24 pages

Animation

Animation

18 pages

Animation

Animation

18 pages

Static

Static

12 pages

Eclipse

Eclipse

23 pages

JAVA

JAVA

24 pages

Arrays

Arrays

29 pages

Animation

Animation

18 pages

Numbers

Numbers

21 pages

JUnit

JUnit

23 pages

Access

Access

18 pages

Applets

Applets

24 pages

Methods

Methods

30 pages

Buttons

Buttons

20 pages

Java

Java

31 pages

Style

Style

28 pages

Style

Style

28 pages

Load more
Loading Unlocking...
Login

Join to view Style Rules I and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Style Rules I and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?