CSSplexity

My talk for the »MuniCSS Finest Meetup« on September 21, 2016 about applying complexity metrics to CSS, a non-programming language.

Transcript

1. CSSPLEXITY APPLYING COMPLEXITY METRICS TO A NON-PROGRAMMING LANGUAGE
2. Servus beinand, I am THOMAS @RASSHOFER
3. METRICS
4. METRICS IEEE Standard 1061
5. METRICS IEEE Standard 1061
6. »Not everything that can be counted counts. Not everything that counts can be counted.« »You can‘t control what you can‘t measure«
7. CRITERIA FOR GOOD SOFTWARE METRICS?
8. CRITERIA FOR GOOD METRICS ▸ Objectivity: no subjective influence ▸ Reliability: same result when applied multiple times ▸ Scaling: there’s a scale for measuring the results ▸ Comparability: measurements can be compared
9. CRITERIA FOR GOOD METRICS ▸ Economic Efficiency: taking measurements has low costs ▸ Usefulness: measurements fulfill practical neeeds ▸ Validity: measurements allow conclusions
10. LOC
12. LINES OF CODE Very simple but also very meaningless. (→ Usefulness and Validity) ▸ lines of »real« code ▸ lines with comments (overall vs. single-line vs. block) ▸ lines mixed up with source and comments ▸ empty lines
13. LINES OF CODE
14. CSS COMPLEXITY & PERFORMANCE ANALYZERS
15. PARKER
16. ANALYZE-CSS
17. ANALYZE-CSS
18. ANALYZE-CSS
19. CYCLOMATIC COMPLEXITY
21. !
22. CYCLOMATIC COMPLEXITY A static source code complexity metric that is calculated by developing a control flow graph of the code. It’s a quantitative measure of the number of linearly independent paths through a program’s source code. !
23. CYCLOMATIC COMPLEXITY Independent paths are defined as paths that have at least one edge which hasn’t been traversed before in any other paths. Control flow depicts a program as a graph which consists of nodes and edges. !
24. CYCLOMATIC COMPLEXITY It can be represented using the formula… ▸ = number of edges in the flow graph ▸ = number of nodes in the flow graph ▸ = number of nodes that have exit points
25. CYCLOMATIC COMPLEXITY In a binary context, it can also be represented using the formula… ▸ = number of predicate nodes (= nodes that contain a condition) (»Amount of decisions plus one«)
26. CYCLOMATIC COMPLEXITY Complexity numbers and their corresponding meanings ▸ 1–10 = structured and well written code, low risk ▸ 11–20 = complex code, moderate risk ▸ 21–50 = very complex code, high risk ▸ >50 = not testable at all, extreme risk
27. CYCLOMATIC COMPLEXITY
28. CYCLOMATIC COMPLEXITY Basically it’s just the number of IFs/ELSEs and counting the number of paths through a program (= the amount of potential outcomes given certain conditions). Rule of thumb: the lower a program’s cyclomatic complexity, the lower is the risk to modify it and the easier it is to understand.
29. CYCLOMATIC COMPLEXITY APPLIED TO CSS
30. CYCLOMATIC COMPLEXITY APPLIED TO CSS Applied to CSS, we’re talking about the number of decisions a browser has to make before it can or can’t style something. Rule of thumb: Every part of a CSS selector is an IF statement. The more IF statements in our selectors, the greater is the selector’s cyclomatic complexity.
31. CYCLOMATIC COMPLEXITY APPLIED TO CSS spiegel.de .column-wide .asset-list-box-hp-special ul li div.video-pic div.image-buttons-panel a span.button.btn-video-text tesla.com .footer-publisher__row--more
32. SELECTORS = SUBJECTS + CONDITIONS .column-wide .asset-list-box-hp-special ul li div.video-pic div.image-buttons-panel a span.button.btn-video-text { // Do something } ▸ Subject (what we actually care about): .btn-video-text ▸ Condition (needless complexity): .column-wide .asset- list-box-hp-special ul li div.video-pic div.image-buttons-panel a span.button
33. EXAMPLES a#content.active > div::first-line [data-content] (number of edges) (number of nodes) (number of nodes that have exit points) !
34. EXAMPLES .column-wide .asset-list-box-hp-special ul li div.video-pic div.image-buttons-panel a span.button.btn-video-text (number of edges) (number of nodes) (number of nodes that have exit points) !
35. EXAMPLES .footer-publisher__row--more (number of edges) (number of nodes) (number of nodes that have exit points) !
36. HALSTEAD METRICS
37. HALSTEAD METRICS ▸ Program vocabulary: ▸ Program length: ▸ Volume: ▸ Difficulty to understand: ▸ Effort to understand:
38. HALSTEAD METRICS ▸ = number of unique operators ▸ = number of unique operands ▸ = total number of operators ▸ = total number of operands
39. HALSTEAD METRICS ▸ Operators = keywords = if, (), {} ▸ Operands = identifiers = foo, bar, 123
40. HALSTEAD METRICS if (a < 5) { if (a > 10) b = b * a; } Unique operators: if, (, ), {, }, >, <=, *, ; Unique operands: a, 5, 10, b
41. HALSTEAD METRICS APPLIED TO CSS
42. HALCSSTEAD IF (is_child()) { IF (is_pseudo_element('first-line')) { IF (is_on('div')) { IF (is_adjacent_sibling()) { IF (is_class('active')) { IF (is_id('content')) { IF (is_on('a')) { … } } } } } } }
43. HALCSSTEAD Unique operators: if, (, ), {, } ▸ ▸
44. HALCSSTEAD Unique operands: is_child, is_pseudo_element, first-line, is_on, div, is_adjacent_sibling, is_class, active, is_id, content, a ▸ ▸
45. HALCSSTEAD / / ▸ Vocabulary: ▸ Length: ▸ Volume: ▸ Difficulty: ▸ Effort:
46. AWESOME. AND NOW?
47. Every time you qualify or nest, you are adding an IF statement. Read these IFs out loud to yourself to try and keep your selectors reasonable.
48. Keep your (cyclomatic) complexity to a minimum. Use tools like CSSplexity, Parker, or analyze-css to get metrics about your selectors.
49. If you don’t really need nestings, don’t put them in there. Sometimes nesting in CSS is necessary. Most of the time it isn’t.
50. Think about your selectors from the right side of life. Start with the bit you know you want, then write as little additional CSS as possible in order to get a correct match.
51. No hacks on the selector intent. Make sure you’re writing the selectors you intend, not just the ones that happen to work.
52. SCSSPLEXITY? LESSPLEXITY? SOON? IT’S UP TO YOU!
53. FINAL WORDS Metrics have to be adjusted to their field of application. There are no universal standards. Define your own set of metrics and their limits for your project. Metrics are no replacement for revisions, tests, or verifications.
55. LINKS Slides: speakerdeck.com/rasshofer/cssplexity CSSplexity: github.com/rasshofer/cssplexity Parker: github.com/katiefenn/parker analyze-css: github.com/macbre/analyze-css Visualization: github.com/rasshofer/cssplexity-visualization sloc: github.com/flosse/sloc
56. LINKS McCabe’s Paper: literateprogramming.com/mccabe.pdf IEEE Standard 1061: cow.ceng.metu.edu.tr/Courses/ download_courseFile.php?id=2681