Results for
Many widely cited code style guides originate from large-scale software engineering contexts: multi-developer teams, large codebases, separate reviewers, and tooling-driven workflows. While those constraints are valid in their domain, they often map poorly onto scientific and engineering scripting as it is typically practiced with MATLAB.
In laboratory and engineering environments, code serves a different role. It is frequently written by individuals or small groups, and then iteratively modified, copied, adapted, and extended as part of an evolving problem-solving process. In this context, the primary priorities are not strict stylistic consistency or tooling compatibility, but rather:
- maintaining clarity of underlying structure,
- minimizing the risk of errors during modification, and
- supporting rapid comprehension of mathematically or logically dense code.
This raises the question: should fixed line-length limits be replaced by context-aware principles? Could these be supported by a suitable AI tool?
The following proposal outlines a small set of heuristics governing line length, based on observations of real-world MATLAB usage, particularly for numerically intensive and structurally rich code. These heuristics aim to:
- preserve and expose meaningful structure (e.g. systems of equations, tables, repeated patterns)
- avoid formatting that obscures relationships or introduces errors, and
- treat different kinds of code (logic vs. data vs. structured expressions) appropriately.
Scope
These principles apply to scientific and engineering scripting, particularly:
- MATLAB-like environments
- numerically or structurally dense code
- monolithic or semi-monolithic workflows
- code that is frequently modified, copied, and adapted
They are not intended for large-scale commercial software engineering, where different constraints dominate.
Core Objective
Line length and formatting should maximize comprehension, structural clarity, and correctness under modification, rather than enforce arbitrary limits.
Hierarchy of Heuristics
Higher-numbered heuristics take precedence over lower-numbered ones.
1) Reasonable Line Length
Code intended for reading should use a reasonable line length, guided by:
- human visual comprehension when scanning
- clarity of expression
- preservation of logical units
This would tend toward 70-100 characters per line, depending on the density.
2) Preserve Semantic Integrity of Lines
Line breaks must not split code in ways that degrade understanding.
Avoid:
- dangling fragments
- very short continuation lines
- separation of tightly coupled elements
- etc.
Prefer:
- keeping logically cohesive expressions intact
- breaking only at clear structural boundaries
One slightly longer line is preferable to two poorly structured lines.
3) Treat Data as Data (Not Prose/Code)
Code that primarily represents data rather than logic is not intended for sequential reading.
This includes:
- large numeric vectors
- lookup tables
- pasted datasets
- etc.
Such code:
- may exceed line length limits without restriction
- should prioritize density and structural stability
- is assumed to be accessed via search or indexing rather than manual parsing
Readability is not the objective; retrievability and integrity are.
4) Preserve and Expose 2D Structure
If code encodes a logical, mathematical, or tabular structure with inherent spatial relationships, it should be represented accordingly.
This includes:
- systems of equations
- tabulated data
- repeated structured expressions
- etc.
Requirements:
- alignment should be used where it improves comprehension
- patterns should be visually apparent
- deviations from patterns should be easily detectable
This principle should be applied strongly, tending toward mandatory use where feasible.
Exception
If a structure would become impractically wide, a compromise representation may be used.
Breaking meaningful spatial structure is considered harmful to comprehension and correctness.
5) Preserve Structural Consistency Across Similar Code
Code segments representing similar or related logic should be expressed in consistent structure and layout.
This applies to:
- repeated formulas
- analogous computations
- structurally similar transformations
- etc.
Consistency enables:
- rapid comparison
- detection of inconsistencies
- safer modification
Similar logic should be represented in similar ways.
Meta-Principles
A. Structure Over Style
Line lengths should reflect the underlying structure of the problem, not conform to arbitrary limits.
B. Correctness Over Convention
Avoid line lengths and formatting that:
- obscures patterns
- hides inconsistencies
- increases the risk of modification errors
C. Optimize for Modification
Code in this domain is frequently:
- edited
- duplicated
- adapted
- extended
Line lengths should reduce the likelihood of errors during these operations, for example by keeping atomic concepts on the same line rather than splitting them up.
D. Anomaly Visibility
Formatting should make unexpected deviations immediately visible.
E. Tool Support
An intelligent tool should:
- respect and preserve structural layout
- avoid rigid line-length enforcement
- detect patterns and inconsistencies
- assist rather than constrain the programmer
I would be interested to hear how well these ideas match others’ experience, particularly in scientific or engineering workflows.
See also:
