0% found this document useful (0 votes)
54 views14 pages

Good Programming Style: Unit 11.3B: System Programming

Code should be written clearly and concisely. It should be modular, with different classes handling different concerns. Variables and functions should have descriptive names. Comments should explain anything not obvious. Exceptions should be caught or allowed to terminate the program gracefully. Overall the code should be easy for others to understand and maintain.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
54 views14 pages

Good Programming Style: Unit 11.3B: System Programming

Code should be written clearly and concisely. It should be modular, with different classes handling different concerns. Variables and functions should have descriptive names. Comments should explain anything not obvious. Exceptions should be caught or allowed to terminate the program gracefully. Overall the code should be easy for others to understand and maintain.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 14

Unit 11.

3B: System programming


Good programming style
Learning objectives :
11.5.3.12 use good programming style rules when writing code

Using a disciplined style of programming will save you time


whenever you have to read your program or debug it.
1. What is a good programming style?
2. In order to maintain a good programming style, what
points should be taken into account?
3. What rules of good code can you provide?
4. Why is it important to follow the rules of good code?
Group work
In groups study and research the rules of good code.
Discuss and select the most effective rules for good code.
Some more specific advice on good coding style
Code formatting:
•Indent your code so that it corresponds to the logical structure of the program.
(If you edit your code in a Java programming environment, the pretty printer will already take of the layout.)

Which code is good example and which is bad example?

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.

Which code is good example and which is bad example?

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?

Good example: Bad example:


Testing:
•Every method written should be tested (even the most trivial one).
•The test should be done in a way that exemplifies the use of code.
•We recommend that for each developed class one develops a corresponding testing class
where each method is tested using one or more methods.
•Be suspicious when testing – test for expected outputs but also for unexpected outputs.
Commenting Code:
•Writing comments is an integral part of the coding – use both multi-line comments (e.g.,
/* */) and in-line comments (e.g., //) where needed.
•Do not over-comment your code – find a good balance.

•Avoid leaving code lines that are commented out in the


final version of your code.
http://www.inf.unibz.it/~nutt/Teaching/DSA1415/DSAAssignments/good-coding-style.html
6 Best Rules for Good Programming Style

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

Code should be easy to read.

It should be easy to understand what the programmer means.

It should be easy to see how the different parts of the program fit into the whole.

Don’t duplicate code. 

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
•……..
•……..

You might also like