eleks.com eleks.com

CODE PRACTICES

HELLO!I am Victor Matyushevskyy

MEET BOB

1.CODE LAYOUT

75 PERCENTSThat much information we percieve though sightHow your code looks matters

A way to better looking code

• Consistent Code Indentation• Consistent Members Ordering• Avoid Deep Nesting• Use Access Modifiers• Limit Line Length

BAD STYLE

BAD STYLE

GOOD STYLE

GOOD STYLE

2.NAMING CONVENTIONS

Reasons for using a convention• Reduce the effort needed to read and

understand source code• Provide additional information about identifier

usage• Provide better understanding in case of code

reuse after a long interval of time• Help avoid "naming collisions"• Enable code reviews to focus on more

important issues• Enhance the aesthetic and professional

appearance of work product

Let’s compare this typical code:float a, b, c; a=9.81; b=5; c=0.5*a*(b^2);

To this self-documenting code:const float gravitationalForce = 9.81;float timeInSeconds = 5;float displacement = (1 / 2) * gravitationalForce * (timeInSeconds ^ 2);

Naming Styles

Pascal CaseDijkstraResult ReconstructShortestPath(Graph graph, Vertex startVertex)

Camel CaseDijkstraResult reconstructShortestPath(Graph& graph, Vertex& startVertex)

Underscore Casedef reconstruct_shortest_path(predecessors, start_vertex, end_vertex)

3.CODEDOCUMENTATION

Comments. Use them to…• Describe code that might be difficult for

someone to follow• In cases of extreme optimization when using

advanced techniques• If you take an approach that might not be

obvious to others• Mark places of code that must be unchanged

for a reason• Describing why things are done the way they

are, not how they work

Commentaries Conventions• Splitting long comments into multiple line

comment • Avoid obvious comments• Place the comment on a separate line, not at

the end of a line of code.• Begin comment text with an uppercase letter• Insert one space between the comment

delimiter and the comment text

Let’s compare this example of a poor commenting style:const float a = 9.81; //gravitational forcefloat b = 5; //time in secondsfloat c = (1/2)*a*(b^2) //multiply the time and gravity together to get displacement

And this documented code, which better explains why it is being done :// Compute displacement with Newton's equation x = vₒt + ½at².const float gravitationalForce = 9.81;float timeInSeconds = 5;float displacement = (1 / 2) * gravitationalForce * (timeInSeconds ^ 2);

4.CODESMELL

CODE SMELL

• Usually is not a bug• Does not prevent the program from

functioning• Indicates weaknesses in design• Might increase risks of a bug in

future

BLOATERS

Long Methods Long Parameter List Large Class

OBJECT-ORIENTATION ABUSERS

Switch Statements Temporary Field Refused Bequest

CHANGE PREVENTERS

Divergent Change Shotgun Surgery Parallel Inheritance Hierarchies

DISPENSABLES

Speculative Generality

Duplicate Code Comments

COUPLERS

Feature Envy Message Chains Middle Man

5.CODEREVIEW

NO REVIEW

WHAT FOR?

• Improves code quality• Detects code smells• Checks for styles and conventions• Knowledge sharing

TWO TYPES OF REVIEW

Design ReviewAnalysis of design and architecture of application.

Code ReviewAnalysis of written code, conventions and styles.

CODE REVIEW PROCESS

Request Review

Review Comments

Refactor

Close Review

Repeat

LET’S REVIEW SOME CONCEPTSLayoutThe way your code is structured is the way it is perceived.

NamesChoosing a better name for variables or type members is a step towards readability.

CommentsLess of them makes you concentrate on code itself. Use them wisely.

SmellLike a rotten apple, youre code can smell, so keep it fresh and clean.

ReviewOne head is good, two is better. Reviewing you code can detect potential bugs and gaps.

ConventionsBefore writing some code know what convetions to use to keep code hygiene consistent.

THANKS!Any questions?

eleks.com

Inspired by Technology.Driven by Value.