CODING FOR "REAL
LIFE"
Safe coding considering software industry
expectations in programming
> whoami
• Boráros-Bakucz András
• Óbuda University, Budapest, Hungary,
Kálmán Kandó Faculty of Electrical Engineering
• Ericsson Hungary Research and Development
Software development, Release Program management
Introduction
• Basic programing courses usually focus on basic level
knowledge without deep understanding of C and C++
compilers
• But some good practices can be learnt early and used
forever… resulting less execution or maintenance cost in
business processes as well
• Problem of large scale, industrial software development
• Quality vs. team development
What Bad Coding may Cause
• Central User Database failed in Great Britain
• 2 month before Olympics in London
• Approx. 18 million people could not use his mobile for more than 20
hours
• Headline in newspapers
Fame
• Nobody
wants…
What Bad Coding may Cause
• Reasons
• Quite new product
• Distributed database system: multiplicated data could never be
totally the same (it must be consistent)
• Tested under overload situations only in lab environment
• Quality issues, for example no stable enough build system
• What happened
• Support/maintenance activity was done during peak hours
• System went inconsistent
• No one really knew how to get it up again
• Support persons downed radio access network links to build location
database from scratch
CODING PRACTICES
Limit all operations
› Limit internal operations, which depends on data content
(internal data consistency)
• No need to behave “good” in case of data inconsistencies (software
faults in our case), but need to handle them smoothly
• No software crash allowed
• Good example: string copy functions
› Use timeout for limiting operations waiting for any kind of
external answer (see later)
Copying Strings
• You should never use strcpy in real life. Why?
• It is an unsafe function rewritten as strncpy which limits the
maximum bytes copied
Copying Strings
Copying Strings
Copy Strings
Copy Strings
Conditional
Practices
“If ifs and ands were pots
and pans
there'd be no work for
tinkers' hands.”
› Exclude everything
possible.
› Do not skip else.
› Most frequently true first.
Exclude everything possible
int main()
{
int f, diff;
f = 9; diff = 1;
while( 1 )
{
printf("%d\n", f );
f = f - diff;
if ( f == 0 ) break;
}
return 0;
}
Exclude everything possible
int main()
{
int f, diff;
f = 9; diff = 2;
while( 1 )
{
printf("%d\n", f );
f = f - diff;
if ( f <= 0 ) break;
}
return 0;
}
• Use “smaller then” instead
of equality check
• Check for value groups
instead of individual values
if possible
Do Not Skip Else
• System managers, software architectures often not
handling negative situations
• Requirement does not say anything what software should do if a
condition does not happen
• Developers always need to think what should happen if
condition does not meet
• Write an else branch all the time and remove only if you are sure
that it concludes on right behavior
• Positive path is only the smaller part of development (~30%)
Do Not Skip Else
• Requirement: if your program receive an “echo-request”
message, send back an “echo-reply”
Do Not Skip Else
› Requirement:
• if your program receive an “echo-request” message, send back an
“echo-reply” message
msg = getmessage();
if ( msg == "echo request" )
{
send( "echo reply" );
}
// ICMP Ping received
// Answer to Ping
Do Not Skip Else
msg = getmessage();
if ( msg == "echo request" )
// ICMP Ping received
{
send( "echo reply" );
// Answer to ICMP Ping
}
else
// Can I expect any other message at this point?
{
if ( msg < 0 )
{
log( "ERROR: Wrongly formatted message received.")
} else
{
log( "WARNING: Not a ping received." );
send( "disconnect" );
}
}
Most frequently
true first
• Requirement:
• Count ‘a’ and ‘e’ letters separately in a string.
Most frequently
true first
for( f=1; f<100; f++ )
{
if( s[f] == 'a' )
{
letter_a++;
}
if( s[f] == 'e' )
{
letter_e++;
}
}
Most frequently
true first
for( f=1; f<100; f++ )
{
if( s[f] == 'a' )
{
letter_a++;
} else if( s[f] == 'e' )
{
letter_e++;
}
}
Most frequently
true first
for( f=1; f<100; f++ )
{
if( s[f] == 'e' )
{
letter_a++;
} else if( s[f] == 'a' )
{
letter_e++;
}
}
You can create the most effective code if most frequently (or
the most probably) “true” condition is put to the first place.
Most frequently
true first
• Requirement:
• Count ‘a’ and ‘e’ letters together in a string.
Most frequently
true first
› Requirement:
• Count ‘a’ and ‘e’ letters together in a string.
for( f=1; f<100; f++ )
{
if(( s[f] == 'e' ) || ( s[f] == 'a' ))
{
letter++;
}
}
Condition evaluation goes left to right, so you should put the
most frequent / probable condition first.
CONCEPTS
Shall I trust input parameters?
• What cases you must check validity in functions’ input
parameters?
• Trust your own software
• Either it is your code or some of your colleagues’ code
• You should trust internal interface descriptions
• No need to check each and every input parameters’ validity
• Do not trust any data received on external interfaces
• External interfaces can be “noisy” or “evil”
• Or disconnected any time (unknown message received)
• In multivendor situation different companies may differently
understood standards
Tales of the Little Bobby Tables
http://xkcd.com/327/
Tales of the Little Bobby Tables
• Sanitize your (database) input
• Check each and every human input and…
• Be protective, just permit what you are prepared for
• For example: hard space, soft space (hyphenation)
Do not Wait Forever
• Use timers to limit operations should be finished by an
external module in a certain time
• Timers counting (mili)seconds and when time expired a
function is executed
• Do not trust your external input,
always protect your code
Fail Fast
• General principle of lean and agile (iterative)
methodologies
• Let your software faults shown as early as possible
• Do not hide problems (for example
unhandled else branches)
• Continuous integration
• Automatized unit testing
• Nightly (or more frequent) builds
• Regression test run
• Visibility of code quality
KISS
› Always remember the KISS principle.
Keep it simple and stupid.
› WP: “A design principle noted by the U.S. Navy in 1960.
Most systems work best if they are kept simple rather than
made complicated; therefore simplicity should be a key
goal in design and unnecessary complexity should be
avoided.”
› Variations: "keep it short and simple" and "keep it simple
and straightforward"
Self Documenting Code
• After two weeks very hard to remember what you did and
why some variables in your very detailed algorithm
• There are more and less self documenting languages
(Pascal vs. C)
• There are some editorial steps you can use for make your
code easy to understand later by you or anyone else
• Proposals:
1.
2.
3.
4.
Descriptive variable names (long)
Descriptive function names
Format source code in a coherent way
Write comments
Coding Rules,
Design Rules
› A set of programming rules must be followed in coding by
all developers
› Give a common base for all new development
› For example:
• Logging and tracing rules
• Software start // order of the components
• Priority of new feature’s threads
• How your code should handle failover or takeover
• GUI rules
Editorial Rules,
Coding Conventions
• Make your code more readable, easier to understand
• All your products’ components’ source code should look
the same
• Contains
• Comment conventions
• Indent style conventions
• Naming conventions
• Best programming practices
• Programming rules of thumb (Rule of three, Pareto, Ninety-Ninety)
• Programming style conventions
• Example: Google C++ Style Guide
Maintainability
• Productified source code goes to maintenance after
deployment
• Effective coding increasing complexity, reducing readability
probably reducing maintainability
• Maintainability versus effectiveness – needs to find the
right balance
METHODOLOGIES
Waterfall and Iterative Methods
• Give me the possibility to handle it as a big chapter…
SUMMARY
Summary: Rule #1
› “Do not assume anything.”
› Check everything, until you are sure how the system,
features or function works
• General positive (non-erroneous) return value is 0
• but printf() returns the number of written bytes to stdout
› Q: Why
scanf( “Give me a number: %d”, &i );
you are not able to type a number there?
Summary: Rule #1
› “Do not assume anything.”
› Check everything, until you are sure how the system,
features or function works
• General positive (non-erroneous) return value is 0
• but printf() returns the number of written bytes to stdout
› Q: Why
scanf( “Give me a number: %d”, &i );
you are not able to type a number there?
(A: Pattern matching.)
› These functions are fossils, but you should not
underestimate the power of “historical reasons”
SOFTWARE
DEVELOPMENT
METHODOLOGIES
Methodologies
• Waterfall
• DSDM
• Prototype model
• RUP
• Incremental
• XP
• Iterative
• Agile
• V-Model
• Lean
• Spiral
• Dual Vee Model
• Scrum
• TDD
• Cleanroom
• FDD
• RAD
Waterfall
• Sequential design
process
• Progress is seen as
flowing steadily
downwards (like a
waterfall) through
SDLC
Waterfall
• Do we know all requirements in the beginning?
• If we have a problem we need to go back several phases.
• Results long project time, usually year or more.
• Slow release cycle.
• Finding problems early is cheaper than later.
• Proven to Waterfall only.
Waterfall #1
• Jump to next phase only if the prior one is completed
• PROs
• Detailed early analysis cause huge advantages at later phases
• If a bug found earlier, it is much cheaper (and more effective) to fix
than bugs found in a later phase
• Requirement should be set before design starts
• Points to importance of documentation (minimized “broken leg”
issue)
• Disciplined and well-structured approach
• Effective for stable software projects
• Easy to plan from project management point of view
Waterfall #2
• CONs
• Changes are expensive
• Client does not explicitly know what he or she wants
• Client does not explicitly know what is possible to have
• Need to finish every phase fully
• Long projects, difficult to keep the plan
• Designers may not know in advance how complex a feature’s
implementation
• “Measure twice, cut once”
Incremental Build Model
• A model between waterfall
and iterative methods
• The model is designed,
implemented and tested
incrementally (a little more
is added each time).
• Finished when satisfies all
the requirements.
• Combines the elements of
the waterfall model with
the iterative philosophy of
prototyping.
• How long test phase
needed – it limits the
minimum length of a
development “increment”
• Non functional
requirements may cause
problems
• Also hard to place the
efforts needed for
development environment
creation
Iterative Methods
• Iterative methods are
different combinations
of both iterative design
or iterative method and
incremental build
model for
development.
Incremental vs. Iterative
Iterative / Prototyping
Effort in Iterative Development
Case Study
• For small impacts
MDE
request
MDE QS
sent back to CU
Start of
Study
OB
WSMD
created
PD0
Study
Backlog
EPP
End of
Study
< 2 weeks
MDE PO
received
Start of
Execution
Execution &
Verification
PD3
Product
Backlog
Node
Release &
Delivery
Prototyping
• Creating prototypes of
software applications
i.e. incomplete
versions of the
software program
being developed
• A prototype typically
simulates only a few
aspects of, and may
be completely different
from, the final product.
Spiral Model
• Combining elements of
design and prototypingin-stages
• Combines the features
of the prototyping and
the waterfall model
• The spiral model is
intended for large,
expensive and
complicated projects
• Advantages of top-down
and bottom-up concepts
Background
• Top-down
• deductive reasoning
• analysis or
decomposition
• Descartes
• G => 1
• Bottom-up
• inductive reasoning
• synthesis
• Bacon
• 1 => G
RAD
• Minimal planning and
fast prototyping.
• Developing instead of
planning
• The lack of preplanning generally
allows software to be
written much faster,
and makes it easier to
change requirements.
Cleanroom
• The Cleanroom process
• This systematic process
embeds software
development and testing
within a statistical quality
control framework.
• Mathematically-based
software development
processes are employed
to create software that is
correct by design, and
statistical usage testing
processes are employed
to provide inferences
about software reliability.
of assessing and
controlling software
quality during
development permits
certification of software
fitness for use at
delivery.
Agile
• Group of software
development methods
• Based on iterative and
incremental development
• Most important phrases
• self-organizing, cross•
•
•
•
functional teams
adaptive planning,
evolutionary development and
delivery,
a time-boxed iterative
approach,
rapid and flexible response to
change.
• A conceptual framework
• The Agile Manifesto in 2001.
Scrum
• Scrum is an iterative and
incremental agile
software development
framework
• A flexible, holistic
product development
strategy
• Development team
works as an atomic unit
• Opposing to sequential
approach
Scrum
• Cross-functional teams
• Competence problems
• Small projects problem
• Verification inside the
teams
• Component test
• Function test
• Early system test
• System test is usually
out of the team
responsibility
Lean (Kanban)
• A translation of lean
manufacturing
principles and
practices
• Toyota Production
System,
• Today part of Agile
community.
Lean Principles
1. Eliminate waste
2. Amplify learning
3. Decide as late as
4.
5.
6.
7.
possible
Deliver as fast as
possible
Empower the team
Build integrity in
See the whole
Extreme Programming (XP)
• Improve software quality
and responsiveness to
changing customer
requirements
• A type of agile software
development
• Frequent "releases" in
short development
cycles
• Introduce checkpoints
where new customer
requirements can be
adopted.
XP Concepts (examples only)
• Pair programming
• Planning game
• Test-driven
development
• Continuous integration
DSDM
• An agile project delivery framework,
• M - MUST: Describes a requirement
primarily
• DSDM fixes cost, quality and time at
the outset and uses the MoSCoW
prioritization of scope
• Pareto principle
that must be satisfied in the final
solution for the solution to be
considered a success.
• S - SHOULD: Represents a highpriority item that should be included
in the solution if it is possible. This
is often a critical requirement but
one which can be satisfied in other
ways if strictly necessary.
• C - COULD: Describes a
requirement which is considered
desirable but not necessary. This
will be included if time and
resources permit.
• W - WOULD: Represents a
requirement that stakeholders have
agreed will not be implemented in a
given release, but may be
considered for the future.
Test-driven development (TDD)
• Relies on the repetition
of a very short
development cycle: first
the developer writes an
(initially failing)
automated test case that
defines a desired
improvement or new
function, then produces
the minimum amount of
code to pass that test,
and finally refactors the
new code to acceptable
standards.
• Test-first programming
concept of extreme
programming in the
beginning
• Today standalone
methodology
Feature-driven development (FDD)
• Iterative and
incremental
development process.
• An Agile method
• Driven from a clientvalued functionality
(feature) perspective
• Mostly part of other
methodologies
• What is needed for the
customer most:
• GUI?
• Perception of the
quality of a SW by
customers?
Rational Unified Process (RUP)
• An iterative software
development process
framework created by
the Rational Software
Corporation (IBM)
• Not a concrete
prescriptive process, but
an adaptable framework,
intended to be tailored
by the development
organizations
• Expected to select
elements of the process
that are appropriate
V-model
• The V-model is an
extension of the
waterfall model.
• Show the relationships
between development
phases and test
phases
• Time and project
completeness vs. level
of abstraction
V-model, complex
Dual V-model
• Describes a model of
complex development
• For example:
• Hardware
• Platform
• Application software
• Development of a system's
architecture is the “big V”
• Components’/entities’
developments are the “small
V”-s
• It shows interactions and
sequences of developing a
complex system and a
system of systems.
Shouldn’t forget
CONCEPTS
Need to be understood
List of Concepts
• Practice
• Design Patterns
• CI
• Testing phases
• Automated testing
• code coverage
• LSV concept
• code review
• Version control
• defect backlog
• Flow approach --
• static code analysis
swedish hospital pres
• UML
• unit test coverage
• SQR
SOFTWARE
DEVELOPMENT FLOW
System Development Lifecycle
Maintenance
Project planning,
feasibility study
7
Acceptance,
installation,
deployment
6
5
1
SDLC
2
Systems analysis,
requirements
definition
Integration
and testing
4
Implementation,
software design
3
Systems design
System Development Lifecycle
Maintenance
Project planning,
feasibility study
7
Acceptance,
installation,
deployment
6
5
1
SDLC
2
Systems analysis,
requirements
definition
Integration
and testing
4
Implementation,
software design
3
Systems design
SDLC – Close to Reality
SDLC
• Project planning, feasibility study: Establishes a high-level
view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project
goals into defined functions and operation of the intended
application. Analyzes end-user information needs.
• Systems design: Describes desired features and
operations in detail, including screen layouts, business
rules, process diagrams, pseudocode and other
documentation.
• Implementation: The real code is written here.
SDLC
• Integration and testing: Brings all the pieces together into a
special testing environment, then checks for errors, bugs
and interoperability.
• Acceptance, installation, deployment: The final stage of
initial development, where the software is put into
production and runs actual business.
• Maintenance: What happens during the rest of the
software's life: changes, correction, additions, moves to a
different computing platform and more. This, the least
glamorous and perhaps most important step of all, goes on
seemingly forever.
Activities and Steps
• Requirements
• Specification
• Architecture
• Construction
• Design
• Testing
• Debugging
• Deployment
• Maintenance
• http://www.computerworld.c
om/s/article/71151/System
_Development_Life_Cycle
• Waterfall might be useful in
case of well determined
req.-s and plans, but
extreme could be better for
less well defined
requirements and prject
plans
Problem of Processes
• Processes
• Good designer, bad designer
• Prepare for average designers
• No need for process if SW
developed by one person
• Quality is far less a question
indeed if someone knows the
whole software alone
• Processes and regular
activities (loops) always
need additional
efforts/people (cost)
• Means expensive…
• But quality is a “must”…
• Or “good enough” quality?
Methodologies
• Waterfall
• RUP
• Prototype model
• XP
• Incremental
• Agile
• Iterative
• Lean
• V-Model
• Dual Vee Model
• Spiral
• TDD
• Scrum
• FDD
• Cleanroom
• RAD
• DSDM