C Style: My favorite C programming practices (2014)

Use of float vs double and numeric types

• Many agree with “default to double” but highlight domains (graphics, ML, embedded) where float is preferable for cache, bandwidth, or lack of hardware double.
• GPUs and some MCUs have severe double‑precision penalties or no double hardware at all.
• Timestamps: some use doubles for convenience; others prefer integer micro/nanoseconds to avoid precision drift. Floats as time storage are called out as risky but common (e.g., games).
• Several argue the real rule is: use double unless you understand your precision/performance needs and can justify float.

Control flow and declarations

• The “never use switch” rule is widely criticized as too rigid; switch is seen as fine when appropriate, though sometimes overused where decomposition would be better.
• Right‑to‑left const and qualifier placement sparks debate: some find it more consistent and easier to reason about; others find it non‑idiomatic or ugly.
• Discussion touches on reading declarations as “what *x is” per classic C rationale.

Performance vs readability and optimization timing

• Broad agreement: design with high‑level performance in mind (algorithms, data structures), but delay micro‑optimizations until profiling.
• Some push back that advice is too vague; examples given where “elegant” chained operations are slower than a simple loop for no readability gain.
• Embedded anecdotes show both extremes: big SoCs where micro‑optimization is largely irrelevant and ultra‑tiny MCUs where tight optimization is essential from the start.

Line length and formatting conventions

• The 79/80‑column hard limit is one of the most contentious points.
• Pro‑80: mirrors typographic research on readable line length; enables multiple vertical editor splits, better diff/merge views, and helps accessibility (Braille displays, large scaling, group code reviews).
• Anti‑80: seen as anachronistic given modern displays; many prefer a soft limit or 100–120 columns, especially with verbose identifiers and languages like Java.
• Consensus: some limit is useful, but a rigid 79‑char rule is widely questioned; long URLs and rare edge cases are cited as exceptions.

Unsigned vs signed integers

• The original “avoid unsigned types” rule is strongly challenged. Critics note signed overflow is UB and thus dangerous under modern optimizing compilers.
• One camp advocates using unsigned everywhere (even for “conceptually signed” math), carefully emulating two’s complement to avoid UB.
• Others respond that integer overflow is usually a bug regardless of type; sanitizers catch it, and avoiding UB alone doesn’t solve logic errors.
• The style‑guide author (later) concedes the rule was a mistake and would drop it, while still preferring signed for many domain‑level quantities so underflows are more meaningful.

Portability, standards, and tools

• Recommendation to target standard C (e.g., -std=c11) instead of dialects (gnu11) draws mixed reactions.
• Some only care about a single compiler (e.g., GCC for an OS) and happily lean on extensions.
• Others value portability across compilers and platforms, using extensions but isolating them behind standard‑conforming interfaces.
• Tools like clang‑tidy and include‑what‑you‑use are mentioned for cleaning includes.

Assessment of the style guide itself

• Several readers say they agree with a large majority of rules but find a few “hard bans” (e.g., on switch, unsigned, 79 columns) unreasonable.
• One detailed breakdown classifies rules from “absolute agreement” (warnings on, include guards, minimizing scope, assert, avoiding VLAs) through “personal preference only” (tabs vs spaces, always using braces) to “just no” (hard 79 chars, enum size constants).
• Some argue many rules are compensating for C’s design flaws (weak namespacing, awkward declarations) and have limited relevance to other languages.

Evolution and meta‑discussion

• The original author returns after a decade, saying their views have shifted: they now rely more on mechanical style enforcement and conventional C style, and see the document as a historical artifact and discussion starter.
• A few commenters express fatigue with perennial debates (tabs/spaces, line length, language of comments) and wish the document focused more on novel, productivity‑enhancing idioms than on well‑worn stylistic controversies.