Naming Variables Is Half of Coding
What's the hardest thing in coding? Algorithms? Debugging? There's actually a famous joke among programmers: "There are only two hard things in computer science โ cache invalidation and naming things."
It's a joke, but it's real. Names of variables, functions, and files serve as the documentation for your code. Name things well and you don't need comments โ you can reopen your code six months later and understand it immediately.
Bad Names vs Good Names
// Bad example
const d = [1.85, 0.42, 2.10, 0.15];
const t = 0.5;
let c = 0;
for (let i = 0; i < d.length; i++) {
if (d[i] >= t) c++;
}
// Good example
const odValues = [1.85, 0.42, 2.10, 0.15];
const odThreshold = 0.5;
let passedCount = 0;
for (let i = 0; i < odValues.length; i++) {
if (odValues[i] >= odThreshold) passedCount++;
}Both code blocks do exactly the same thing. But the second one immediately tells you "this counts OD values that meet or exceed a threshold." You could never know that from d, t, c.
Four Naming Styles: When to Use What
The rules for naming things in code are called naming conventions. There are four main styles:
| Convention | Format | Used For | Example |
|---|---|---|---|
| camelCase | First word lowercase, rest capitalized | Variables, functions | sampleCount, getGeneInfo() |
| PascalCase | Every word capitalized | Classes, React components | GeneCard, SampleList |
| snake_case | Lowercase + underscores | Python variables/functions, filenames | sample_count, gene_info.py |
| SCREAMING_SNAKE | Uppercase + underscores | Constants | MAX_RETRY, OD_THRESHOLD |
In JavaScript, camelCase is the default. In Python, snake_case is the default. These are conventions of each language community โ following them makes your code easier for other developers to read.
// JavaScript (camelCase)
const sampleCount = 96;
function calculatePassRate(samples) { /* ... */ }
// React component (PascalCase)
function GeneCard(props) { /* ... */ }
// Constants (SCREAMING_SNAKE)
const MAX_OD_VALUE = 4.0;
const MIN_SAMPLE_VOLUME = 0.5;Bio Data and Naming: Real-world Challenges
When coding with biotech data, there are unique naming challenges. How do you translate gene names, database identifiers, and analysis parameters into variable names?
Different Organizations Use Different Gene Naming Rules
| Organization/DB | Gene Format | Example |
|---|---|---|
| NCBI (Gene) | Uppercase italic (human) | TP53, BRCA1 |
| ENSEMBL | ENSG + numeric ID | ENSG00000141510 |
| UniProt | Protein_species abbreviation | P53_HUMAN |
| HGNC | Official symbol (uppercase) | TP53, EGFR |
Since you can't use italics in code, you need rules when converting to variable names:
// Gene names as plain strings
const geneName = "TP53";
const ensemblId = "ENSG00000141510";
// Working with multiple genes
const targetGenes = ["TP53", "BRCA1", "EGFR"];
// Analysis result object
const geneExpression = {
TP53: 12.4,
BRCA1: 8.7,
EGFR: 15.2
};Gene names themselves (TP53) are data, so they go in as strings. The variables holding them (geneName, targetGenes) use camelCase.
Good Bio Variable Name Examples
| Bad Name | Good Name | Reason |
|---|---|---|
data | qcResults | Clear what kind of data |
val | odValue | Clear which value |
list | failedSamples | Clear what's in the list |
flag | isPassed | Booleans start with is/has |
n | sampleCount | Clear what's being counted |
temp | rawSequence | Don't give up on naming just because it's "temporary" |
res | apiResponse | Full words over abbreviations |
Five Principles of Naming
1. Reveal intent
The variable name alone should tell you "what this is." elapsedDays over d, currentIndex over x.
2. Don't abbreviate
count over cnt, button over btn, message over msg. Autocomplete makes typing time identical. Exception: abbreviations that are deeply established conventions: id, url, api, db.
3. Booleans start with is/has/can
const isPassed = od >= 1.0;
const hasPermission = user.role === "admin";
const canDelete = hasPermission && !isLocked;Just passed is ambiguous โ is it "the thing that passed" or "whether it passed"? isPassed clearly means true/false.
4. Functions start with verbs
function calculatePassRate(samples) { /* ... */ }
function fetchGeneData(geneId) { /* ... */ }
function formatDate(timestamp) { /* ... */ }Functions are actions, so verbs are natural. calculatePassRate() immediately tells you "this function calculates the pass rate" โ passRate() doesn't.
5. Be consistent
Using get, fetch, retrieve, and load for "getting something" within one project creates confusion. Pick one and use it consistently. In team projects, document this rule.
File and Folder Names
Rules aren't just for variables. Files and folders follow conventions too:
| Target | Convention | Example |
|---|---|---|
| JavaScript files | camelCase or kebab-case | geneUtils.js, gene-utils.js |
| React component files | PascalCase | GeneCard.tsx, SampleList.tsx |
| Python files | snake_case | gene_analysis.py, qc_report.py |
| CSS classes | kebab-case | gene-card, sample-list |
| Environment variables | SCREAMING_SNAKE | DATABASE_URL, API_KEY |
kebab-case connects words with hyphens (-). It's mainly used in URLs and CSS.
Conclusion: Names Are Code's First Impression
Spending time on good names isn't a waste. Code is written once and read dozens of times. If it takes 30 extra seconds to write but saves 10 seconds every time someone reads it โ that's an investment.
Just as a reviewer would reject a paper with axis labels like "value1" and "value2," naming variables d, t, c in your code makes your future self suffer.