Good Programming Style: Unit 11.3B: System Programming
Good Programming Style: Unit 11.3B: System Programming
Good example:
Bad example:
•Try to create a good measure of vertical density of your code (new lines between
commands) and keep it consistent
Which code is good example and which is bad example? Good example:
Bad example:
Variables:
•Use meaningful variable names. The name should reveal the usage intent.
Good example:
Bad example:
•If the variable name does not sufficiently describe the usage intent,
comment on the variable at its declaration.
•It is a good practice to declare a global variable for each parameter of the method that is
given as a concrete value.
Which code is good example and which is bad example?
b i l i ty
e a da M aintaina
R b i l i ty
e n t s
o m m N a m i n
C ti o n g
de n t a O utpu
In t
Successful criteria: can explain the Rules for Good Programming Style
https://
www.thecrazyprogrammer.com/2014/08/8-best-rules-for-good-programming-styl
e.html
Readability
Good code is written to be easily understood by colleagues. It is properly and consistently formatted and uses clear, meaningful names for functions and variables.
Concise and accurate comments describe a natural decomposition of the software’s functionality into simple and specific functions. Any tricky sections are clearly
noted. It should be easy to see why the program will work and reason that it should work in all conceivable cases.
Maintainability
Code should be written so that it is straightforward for another programmer to fix bugs or make changes to its functionality later. Function should be general and
assume as little as possible about preconditions. All important values should be marked as constants which can be easily changed. Code should be robust to handle
any possible input and produce a reasonable result without crashing. Clear messages should be output for input which is not allowed.
Comments
Comments are the first step towards making computer program human readable. Comments should explain clearly everything about a program which is not obvious
to a peer programmer. The volume of comments written is meaningless, quality is all that counts. They should go at the top of every source
file and generally include your name, the date your code was written and overall description of the purpose of that program.
Naming
Names given to classes, variables, and functions should be unambiguous and descriptive. Other guidelines for naming are:
Capitalization is used to separate multi-word names: StoneMasonKarel.
The first letter of a class name is always capitalized: GraphicsProgram
The first letter of a function or variable name is always in lowercase: setFilled().
The names x and y should only be used to describe coordinates.
The names i, j, and k should only be used as variables in for loops.
Indentation
Indentation is used to clearly mark control flow in a program. Within any bracketed block, all code is indented in one tab. This includes the class body itself. Each
additional for, while, if, or switch structure introduces a new block which is indented, even if brackets are omitted for one line statements. For if statements, any
corresponding else statements should line up
Output
A final, overlooked aspect of good programming style is how our program output results and information to users. Part of writing professional looking programs is
providing clear instructions and results to the users of our programs. This means proper English with no spelling error conditions. One must always assume that
writing programs to be used by somebody with no understanding of computer programming whatsoever. If you liked the article then please share it!
Summary
It should be easy to see how the different parts of the program fit into the whole.
Write modular code. Different concerns should be handled by different classes, and where
possible even different methods within one class.
Formative assessment `Programming Style`
11.5.3.12 use good programming style rules when writing code
This example shows how a thrown exception is passed back to the calling method, and to the method that called that one,
and so on until a catch clause is found or the main method is reached.
Here is a class written in a common Java style, illustrating
a number of the style guidelines.
Try to do good style if you prefer a different style is
considered acceptable and explain.
• Compare values
• Simplicity
• Clarity of nested comparisons
• Unnecessary variables
For example:
This example illustrates:
•single spaces between most reserved words, identifiers
and symbols
•single blank lines between methods
•……..
•……..