Which programming case do you prefer (for MATLAB code)?
Chen Lin
홍보했습니다
설문은 2026년 6월 30일에 종료됩니다.
camelCase (variableName)
38%
PascalCase (VariableName)
11%
no capitalization (variablename)
5%
snake_case (variable_name)
29%
It varies for me
16%
추천 수: 347
댓글 수: 12
시간 내림차순
I use camelCase for variables because it makes the variable names shorter than snake case and it's still just as readable. However I use PascalCase for function names because I'm used to having the first letter of all function names capitalized. Maybe it's a habit carried over from Visual Studio and Visual Basic.
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.
Well dpb, I'm going to disagree with you on this. When I see code that is an alphabet soup of non-descriptive single and double letter variables, it looks like a confusing mess to me and it takes longer for me to understand it because I have to backtrack through code to find out what x, a, n, pr, dc, etc. really mean. I'd much rather see
firstPixel = find(binaryImage(row, :), 1, 'first') % Find the first "true" pixel on this row of the binary image.
than
fp = find(b(r,:), 1, 'first')
Load up the script with hundreds of lines like the latter and I don't know what the heck is going on.
Another example seen commonly
[m, n] = size(img);
or
[x, y] = size(img);
Then people will go on coding thinking that m or x is the width of the image. A short cryptic variable name can be misleading. A better way would be
[rows, columns] = size(grayImage);
[rows, columns, numberOfColorChannels] = size(rgbImage);
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.
참여하려면 로그인하세요
