week 9 summary

Gergő Pintér, PhD

gergo.pinter@uni-corvinus.hu

code quality

agile
working software over comprehensive documentation
software craftmanship
not only working software, but also well-crafted software
well-crafted
  • high quality
  • well-designed
  • validated and verified
  • tested
  • code is clean, easy to understand and maintain

code smell

a code smell is a surface indication that usually corresponds to a deeper problem

– Martin Flower [1]

software rot is the degradation, deterioration, or loss of the use or performance of software over time [2]

requirement smell: signs in the requirements that are not necessarily wrong but could be problematic [3]

clean clode violations as code smells

  • long method
  • long parameter list
  • naming
    • notation in names
    • inconsistent names
    • uncommunicative names
  • comments
  • large class
    • possibly do more than one thing
  • a function / class does more than one thing
  • magic number
  • duplicated code
  • speculative generality
  • dead code
  • too complexity comditions
  • feature envy
  • bad comment
    • obsolete, redundant (noise), commented-out code

source: [4], [5]

how to measure code quality?

it is hard to objectively measure the quality of code

  • number of source lines of code (SLOC)
  • style guide compliance – is the code clean?
  • Halstead metrics
  • cyclomatic complexity – is the code simple?
  • maintainability index
  • test coverage – is the code tested?

cyclomatic comlexity

  • developed by Thomas J. McCabe in 1976
  • quantitative measure of the number of linearly independent paths through the source code
  • computed using the control-flow graph of the program

defined as:

M=E−N+2P M = E - N + 2P

  • E: the number of edges of the graph
  • N: the number of nodes of the graph
  • P: the number of connected components
    • for a single method, P always equals 1

cyclomatic comlexity – example

def calculate_progress(
    finished: int,
    total: int,
    as_percentage: bool,
    foo: bool
) -> float:
    progress = finished / total

    if as_percentage and foo:
        return progress * 100
    else:
        return progress

activity diagram

control flow

CC=E−N+2 CC = E - N + 2 CC=7−6+2 CC = 7 - 6 + 2 CC=3 CC = 3

WTF per minute

own drawing based on Glen Lipka’s

V model [6]

  • each phase has output and a review process
    • errors are found at early stage
    • decreases the risk of failure
  • testing is done in a hierarchical perspective
based on guru99.com’s image

requirement analysis review

user story map
  • can be discussed / reviewed
  • even with a customer representative

user story “reviewed” in an issue tracker

architecture review

C4 diagrams as the output of the high level design

risk storming as a review process

code review

def query_progress(user_id:int) -> float:
    # establish connection
    con= sqlite3.connect("data.db")
    # build query
    progress_query = f"""
    SELECT
        lesson / 50.0 AS progress
    FROM activity
    WHERE
        user_id = {user_id} AND
        result = 'success'
    ORDER BY
        lesson DESC
    LIMIT 1
    ;
    """
    # execute query
    res =con.execute(progress_query)
    progress=res.fetchone()[0]
    return progress
  • does not respect style guide
  • does 3 things
    • establish DB connection
    • build query
    • execute query
  • contains separation comments
  • hard coded divisor
    • magic number

every work product can and should be reviewed

review types by formality

type formality led by effort documentation
informal not formal noone minimal undocumented
walkthrough not formal1 authors very low normal, fault-finding
technical less formal trained moderator, not the author moderate more detailed
inspection most formal trained moderator high thorough; based on standards, checklists

review – author’s perspective

  • be humble
    • mind that everybody’s code can be improved
    • you are not perfect, accept that you will make mistakes
  • open to feedback
  • you are not your code
  • the goal is to deliver higher quality code, not about arguing who was right
    • you and the reviewer are in the same side
  • you and the reviewer are not only talking about the code,
    • you are exchanging best practices and experiences
  • you can learn from the review

source: Code Review Guidelines for Humans [7]

review – reviewer’s perspective

  • use I-messages
  • talk about the code, not the coder
  • ask questions instead of making statements
  • refer to the behavior, not the traits of the author
  • accept that there are different solutions
  • respect and trust the author
  • mind the OIR-rule of giving feedback
    • observation, impact, request
  • before giving feedback, ask yourself:
    • is it true? (opinion != truth)
    • is it necessary? (avoid nagging, focus on the current work product)
    • is it kind? (no shaming)
  • be humble; you are not perfect and you can also improve
  • it’s fine to say: Everything is good!
  • don’t forget to praise

source: Code Review Guidelines for Humans [7]

references

[1]
M. Fowler, “Code smell.” https://martinfowler.com/bliki/CodeSmell.html , 09-Feb-2006.
[2]
Wikipedia contributors, “Software rot — Wikipedia, the free encyclopedia.” https://en.wikipedia.org/w/index.php?title=Software_rot&oldid=1236668404 , 2024.
[3]
H. Femmer, D. M. Fernández, S. Wagner, and S. Eder, “Rapid quality assurance with requirements smells,” Journal of Systems and Software, vol. 123, pp. 190–213, 2017.
[4]
J. Atwood, “Code smells.” https://blog.codinghorror.com/code-smells/ , 18-May-2006.
[5]
R. C. Martin, Clean code: A handbook of agile software craftsmanship. Pearson Education, 2009.
[6]
K. Forsberg and H. Mooz, “The relationship of system engineering to the project cycle,” Center for Systems Management, vol. 5333, 1991.
[7]
P. Hauer, “Code review guidelines for humans.” https://phauer.com/2018/code-review-guidelines/ , 31-Jul-2018.

  1. Sometimes it can be somewhat formal.↩︎