SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Creating your own
Dr. Ir. Philippe Faes
● What is coding style
● Purpose of a coding style
● Types of coding rules
● Quality criteria for coding rules
● Enforcing coding style
What is a coding style?
Programming style is a set of rules or guidelines used
when writing the source code for a computer program. It is
often claimed that following a particular programming style
will help programmers to read and understand source code
conforming to the style, and help to avoid introducing
Brought to attention in 1974 by Kernighan and Plauger
book: “The Elements of Programming Style”
[coding | programming | style] [style | conventions | rules]
What is its Purpose?
● Increase readability and maintainability
● Reduce risk of defects
Try to avoid this, but we won’t complain if you
break this rule.
Avoid this. You have to document when you
break this rule.
Don’t break this rule. No excuses.
Useful rules are rules that have important
implications, and there is a good reason for
having this rule, even if there may be
arguments against it.
Arbitrary rules don’t have large practical
implications. Sometimes arbitrary rules are
used for consistency.
Adverse rules don’t have any benefit. The
claimed benefit may be incorrect or outdated.
How to read rules
Useful rules: examples
● sensitivity lists
● rules for clock domain crossing
● recommended third-party or in-house libraries
● deprecated libraries
● style for Finite State Machines
● reset strategy, initial values of signals or
● allowed / disallowed preprocessor code
Arbitrary rules: examples
Usually rules that improve code consistency.
● Capitalisation: UPPER and lower case
● Indentation and whitespace
● Naming conventions like rst_n
● File structure, copyright headers
Formalise what you have.
Don’t overdo these rules.
Many rules that include “weasel terms” like:
○ “... may result in larger circuit”
○ “... may result in slower clock speed”
● Is this documented?
○ Can I verify this for my current synthesis tool?
○ Which code snippet and with which tool chain?
=> TEST it yourself
● Is it important?
○ error-free, on time, on budget
versus saving two LUTs or 5% of clock speed
=> use common sense
“Some synthesis tools may not support this.”
Ask youself: which synthesis tools?
(not AcmeSynth from 1994?)
If you sell IP cores, you may have to adhere to the
greatest common denominator of current (not historical!)
If you build your own design, you should only worry about
your current tool chain, or a few common and modern tool
Not supported for synthesis?
Do NOT start from somebody else’s style book!
● You are prone to copy their errors
● Instead: read a few style books and then put
them away for a week.
● Be critical of rules and validate their reason
How to start writing
your own style guide
Example stylebook structure
● file and directory structure and naming
● file headers, what to put in a file
● naming conventions