Which programming case do you prefer (for MATLAB code)?
Chen Lin
featured this
Poll will close on 30 Jun 2026
camelCase (variableName)
38%
PascalCase (VariableName)
12%
no capitalization (variablename)
4%
snake_case (variable_name)
27%
It varies for me
19%
134 votes
10 Comments
Time Descending
I prefer snake case for most variable names, mainly because it is different than the capitalization styles used by MathWorks developers for other kinds of identifiers. It was a common capitalization style for C, back when I started programming with it in the late 1980s, so I was familiar and comfortable with it. I was disappointed that the recent coding style documentation provided by MathWorks specified a variable naming style that is the same as that used for function names.
For variable names that are based on mathematical symbols, I usually capitalize to approximate the symbols. For example, I'll use H for the Fourier transform of h, and I'll use Fs to mean sampling frequency.
I think you know who to blame for that standard 👀! I was one of the louder voices in the variable naming standards. I tried to leave room for Cleve's beautiful mathematical style and reflect common usage patterns in the examples that we ship with MATLAB (with a bias towards longer, more readable names, where appropriate).
And I think you know I've never been a fan of snake case. I also like kebab-case lately for naming some things, but that's because I've been living in the world of GitHub and AI tools.
It wasn't my intent to give you a hard time here, Michelle. You and I together learned to face the reality that every standardization effort will make at least some people unhappy. 🤷♂️ This is just a situation where I will take advantage of my MathWorks retirement to go my own way. 🙂
I kind of like kebab-case (variable-name), as hyphens are easier to repeatedly type than underscores. But it is not supported in MATLAB, due to ambiguity with subtraction, given the first-class status of that operation.
"(with a bias towards longer, more readable names, where appropriate)."
If there is one specific thing I do detest and strongly dislike the trend in MATLAB, it is the excessive length names. I think all the extra is more visual clutter to wade through to see the actual form than the name information can possibly make up for. If there's possible amibiguity or may abbreviating is hard, that's what comments are for.
Comments can become out of date as code changes. Well-thought names for variables, functions, classes, etc. help reduce the context required for understanding.
I am not saying that comments are always bad. Rather, they should convey supplemental information, like why a certain approach/algorithm was used, reference materials, etc.
Which names are you referring to @dpb? Names from functions shipped by MathWorks, names in code you see people use, or something else?
On reflection, I guess most of it comes from user code more than actual Mathworks-distributed code, although some of the named parameter names can get pretty bulky, if the code completion is working, one can generally use the tab comletion.
Why write
datFiledDrListing=dir('*.dat');
when
d=dir('*.dat');
is as good and it's clear from context what it is (and is virtually always going to be local and consumed immediately thereafter)? If the output is returned to a caller, there's a place where more description may well be warranted.
On the other observation, I can't think of the last time I actually thought it was necessary to comment on what a variable name abbreviation used really meant; only that I'd resort to that if I couldn't think of a good naming convention over having one that seemed overly long (and I'll admit I don't have a hard and fast rule on what too long is). We made do with a maximum of 6 in F77 while some early BASIC dialacts were one letter and an optional digit.
Charles Moore (the inventor of FORTH) was a master at writing code that read like a novel and rarely used names over 8-10 characters. Then again, he was unique in minimalist.
I'm a big fan of short variable names when you can get away with them. We captured this in the MATLAB Coding Guidelines:
---
Description: Prefer descriptive names for variables. Short variables names are permissible when the variable's meaning can be easily determined from the context in which it is used. Such cases include:
- Mathematical expressions
- Short blocks of contiguous code
- Temporary variables or iterators in a loop
- Values widely known to users in a particular domain (Mathematics: phi = golden ratio, Physics: h = Planck's constant)
---
Pulling on your example - it's highly likely that the variable d is used over just a few lines of code following the call to dir. I think d is a perfect variable name here. But if I'm reading a messy 1,000 line function and I find d referenced nowhere near it's definition, it's likely going to take more work to figure it out. Context might help, but sometimes a more descriptive name can be helpful, too. I've also seen that larger teams working on a code base can benefit from consistent naming styles, often a bit more descriptive, to make it easier to jump into bits of each other's code.
No real arguments -- I'm just railing against
longdrawnoutvariablenameswhensuperfluoustomeaning=false;
Sign in to participate
