1. Safe coding considering software industry expectations in programming
Coding for "real life"
Safe coding considering software industry expectations in programming

2. > whoami Boráros-Bakucz András
> 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

3.
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

4. What Bad Coding may Cause
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

5.
Fame
Nobody wants…

6. What Bad Coding may Cause
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

7. Coding Practices

8. 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)

9. Copying Strings You should never use strcpy in real life. Why?
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

10.
Copying Strings

11.
Copying Strings

12.
Copy Strings

13.
Copy Strings

14. Conditional Practices
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.

15. Exclude everything possible
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;

16. Exclude everything possible
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

17.
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%)

18. Do Not Skip Else
Requirement: if your program receive an “echo-request” message, send back an “echo-reply”

19. 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" ) // ICMP Ping received {
send( "echo reply" ); // Answer to Ping }

20. 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" );

21. Most frequently true first
Requirement:
Count ‘a’ and ‘e’ letters separately in a string.

22. Most frequently true first
for( f=1; f<100; f++ ) { if( s[f] == 'a' ) letter_a++; } if( s[f] == 'e' ) letter_e++;

23. Most frequently true first
for( f=1; f<100; f++ ) { if( s[f] == 'a' ) letter_a++; } else if( s[f] == 'e' ) letter_e++;

24. Most frequently true first
for( f=1; f<100; f++ ) { if( s[f] == 'a' ) letter_a++; } else if( s[f] == 'e' ) letter_e++; }

25. 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.

26. Most frequently true first
Requirement:
Count ‘a’ and ‘e’ letters together in a string.

27. 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.

28. Concepts

29. Shall I trust input parameters?
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

30. Tales of the Little Bobby Tables

31. 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)

32.
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

33.
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

34. Keep it simple and stupid.
KISS
Always remember the KISS principle.
Keep it simple and stupid.
WP: “A design principle noted by the U.S. Navy in 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"

35.
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:
Descriptive variable names (long)
Descriptive function names
Format source code in a coherent way
Write comments

36. Coding Rules, Design Rules
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

37. Editorial Rules, Coding Conventions
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

38.
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

39. Methodologies

40. Waterfall and Iterative Methods
Give me the possibility to handle it as a big chapter…

41. Summary

42. Summary: Rule #1 “Do not assume anything.”
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?

43. Summary: Rule #1 “Do not assume anything.”
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”

44. Software Development methodologies

45. Methodologies Waterfall Prototype model Incremental Iterative V-Model
Spiral
Scrum
Cleanroom
RAD
DSDM
RUP XP
Agile
Lean
Dual Vee Model
TDD
FDD

46. Waterfall Sequential design process
Progress is seen as flowing steadily downwards (like a waterfall) through SDLC

47. 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.

48. 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

49. 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”

50. 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

51. Iterative Methods
Iterative methods are different combinations of both iterative design or iterative method and incremental build model for development.

52. Incremental vs. Iterative

53. Iterative / Prototyping

54. Effort in Iterative Development

55. Case Study For small impacts EPP Node Study Product Backlog Backlog
MDE request
MDE QS
sent back to CU
MDE PO received
Start of
Study
End of
Study
Start of
Execution
WSMD
created
Execution &
Verification
Release & Delivery OB
< 2 weeks
PD0
PD3
Study
Backlog
Product
Backlog
EPP
Node

56. 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.

57. Spiral Model Combining elements of design and prototyping-in-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

58. Background Top-down Bottom-up deductive reasoning
analysis or decomposition
Descartes
G => 1
Bottom-up
inductive reasoning
synthesis
Bacon
1 => G

59. RAD Minimal planning and fast prototyping.
Developing instead of planning
The lack of pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

60. Cleanroom
The Cleanroom 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.
This systematic process of assessing and controlling software quality during development permits certification of software fitness for use at delivery.

61. 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.

62. 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

63. Scrum Cross-functional teams Verification inside the teams
System test is usually out of the team responsibility
Competence problems
Small projects problem
Component test
Function test
Early system test

64. Lean (Kanban)
A translation of lean manufacturing principles and practices
Toyota Production System,
Today part of Agile community.

65. Lean Principles Eliminate waste Amplify learning
Decide as late as possible
Deliver as fast as possible
Empower the team
Build integrity in
See the whole

66. 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.

67. XP Concepts (examples only)
Pair programming
Planning game
Test-driven development
Continuous integration

68. DSDM An agile project delivery framework, primarily
DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritization of scope
Pareto principle
M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
S - SHOULD: Represents a high-priority 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.

69. 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

70. Feature-driven development (FDD)
Iterative and incremental development process.
An Agile method
Driven from a client-valued 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?

71. 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

72. 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

73. V-model, complex

74. 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.

75. Shouldn’t forget

76. Concepts
Need to be understood

77. List of Concepts Practice CI Automated testing LSV concept
Version control
Flow approach -- swedish hospital pres
UML
Design Patterns
Testing phases
code coverage
code review
defect backlog
static code analysis
unit test coverage
SQR

78. Software Development Flow

79. System Development Lifecycle
Maintenance 7 1 2 3 4 5 6
Project planning, feasibility study
Acceptance, installation, deployment
SDLC
Systems analysis, requirements definition
Integration and testing
Implementation,
software design
Systems design

80. System Development Lifecycle
Maintenance 7 1 2 3 4 5 6
Project planning, feasibility study
Acceptance, installation, deployment
SDLC
Systems analysis, requirements definition
Waterfall vs. extreme models
Integration and testing
Implementation,
software design
Systems design

81. SDLC – Close to Reality

82. 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.

83. 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.

84. Activities and Steps Requirements Specification Architecture
Construction
Design
Testing
Debugging
Deployment
Maintenance
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

85. 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?

86. Methodologies Waterfall Prototype model Incremental Iterative V-Model
The incremental model divides the product into builds, where sections of the project are created and tested separately.
Build and fix: write some code, then keep modifying it until the customer is happy. Without planning, this is very open-ended and can by risky.
Waterfall
Prototype model
Incremental
Iterative
V-Model
Spiral
Scrum
Cleanroom
RAD
DSDM
RUP XP
Agile
Lean
Dual Vee Model
TDD
FDD
In the rapid prototyping (sometimes called rapid application development) model, initial emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness. The prototype is an essential part of the requirements determination phase, and may be created using tools different from those used for the final product.