Not so rhetorical question: Why the common practice of writing lines of code without white space?

49 views (last 30 days)
I wanted to ask this of MathWorks, because they start the habit in their docs, but I didn't find a place to ask them... so...
I am working with new MATLAB students at the undergrad and grad levels, and they all cram their lines of code together without white space. When I ask them why, in light of other written materials, such as their texts, journals, etc., that use white space effectively, they use no white space in their MATLAB code, they invariably reply that they see it that way in the MATLAB docs, and assume that it is the "correct" way to write MATLAB code. Whilst it is easy enough for the author of a code fragment to read his own code, readability for others suffers significantly when white space is removed.
Is this
really as easy to read as this
scDSI (:, theta+1) = scRadius * [ cosd(theta); sind(theta); 0.0 ]?
If I copy an example from the docs to use as my template for a command that is new to me (so I don't already know the syntax by heart), I get, for example,
I'm pretty sure that the use of white space for readability in code is a recommended practice, so why does MathWorks foster the opposite in their docs?
And if this should be a question for MathWorks, where do I send it?
Andreas Goser
Andreas Goser on 11 Jan 2015
There is a team at MathWorks looking at programming standards for code in demos, doc, etc. If the responses here are not sufficient for you, please send me a PN or email and I will try to get you in touch with that team.

Sign in to comment.

Answers (5)

John D'Errico
John D'Errico on 11 Jan 2015
Edited: John D'Errico on 11 Jan 2015
I think the point is whitespace is good. Well, good to some extent. Gosh, like whitespace, water is good for me, or so my doctor says. But too much water, and it can kill a person. To extend the simile, some of us need more water than others.
So, yes, whitespace is good to the extent it makes your code easier to read. Tightly packed code is difficult to read, especially if it is complicated code. Your example however, overdoes it for me.
scDSI (:, theta+1) = scRadius * [ cosd(theta); sind(theta); 0.0 ]
I prefer to use some white space, but NEVER between a function and the parens in a function call. So I would eliminate the first blank you had in there, and maybe a few more. I'll usually have space between operators and their operands. So for me, + and - deserve spaces around them. I tend not to use whitespace around * and ^ operators.
scDSI(:,theta+1) = scRadius*[cosd(theta); sind(theta); 0.0]
Anyway, you were inconsistent! If you want a space after scDSI, then why not want to put one after the calls to sind and cosd? Of course, that screws up the parser. Remember that when you use whitespace it is also the equivalent of a comma. So you might also cause confusion by too much whitespace. How should this next line be interpreted?
X = [ cosd (1:10) ];
Error using cosd
Not enough input arguments.
Yes, MATLAB gets upset there. So my point is, for consistency, whitespace between a function and the paren that follows it is a bad idea, because it may SOMETIMES be interpreted incorrectly.
Similarly, see my answer to this recent question. There, we saw the line:
temp2=[13.796, 13.863, 13. 865, 13.893, 13.881];
Clearly there is a typo in the line. It might better have been written as:
temp2=[13.796, 13.863, 13.865, 13.893, 13.881];
But arguably, the typo would have been even easier to see if no whitespace at all was inserted!
temp2=[13.796,13.863,13. 865,13.893,13.881];
WHOOPS! To me, that seems a clear typo now.
Whitespace is good. But don't overdo it. And recognize that everyone has a different tolerance for whitespace. Just like comments in code, and in a function header. Personally, I like them. I think more of them are better than less. But some people think I overdo it, that I write too much, too complete help. Either way, it is not worth getting upset over because we need to recognize that everyone is different, and has different programming styles.

dpb on 9 Jan 2015
...Is [compactline] really as easy to read as this [brok en line]?
In my view, yes, the compact version is as legible (or, more precisely, I think the suggested line is less legible).
I do NOT like excessive spaces such as the introduction of a space between the variable name and the subscripting expression particularly; that destroys imo the association.
I don't mind separating the RHS and LHS and, judiciously applied, separating (say additive) terms in a long expression can be of some benefit but to do so excessively just because there is a '+' sign present adds nothing in my view; use the spacing as one would commas in a sentence--sparingly and to make a specific lexical point.
It's far better to have more consistency whatever the style chosen than any arbitrary number of spaces or placing of same. The biggest gripe I have with much of the code posted is the seemingly interminable length of variable names and the penchant to not break long lines of code into either multiple lines via a few temporaries or by the continuation ellipses.
You can submit suggestions to TMW for updates/modifications to documentation via the CONTACT point on the main page.
dpb on 12 Jan 2015
Edited: dpb on 16 Jan 2015
... how do I remember if it's [one of various spellings]...
How do you remember when it's spelled out in its entirety what the next word is? It's all got to go back to the documentation anyway.

Sign in to comment.

Stephen23 on 11 Jan 2015
Edited: Stephen23 on 11 Jan 2015
I have a different hypothesis: perhaps this is a mathematician vs. programmer characteristic?
It is programmers who obsess about whitespace, the lack or the meaning thereof, and this is reflected in many programming languages' codes of best practice, and the endless flamewars about Python. This could be due to the structure and overall flow of the text being seen as a parallel to the structure of the program itself, and a reflection of a good algorithm implementation, therefore careful use of whitespace is used to show the flow of the whole program.
Mathematicians are perhaps much more used to keeping things together, particularly operators and arrays, where the conceptual groups are seen as some kind of atomic unit: it represents one abstract thing that is being manipulated or assigned, and so the visual importance is to represent it as one thing.
  • a programmer sees "this is value A times value B" (and so uses whitespace to make it clear that this is an operation on two variables)
  • a mathematician sees "this is the product of values A and B" (and so groups them together into one atomic concept).
This hypothesis also explains the tendency in MATLAB to use very short (one letter!) variable names, so while most programmers have a heart attack at the mere thought of this, all of mathematics is taught using x, y, k, A, B,... as typical variable names. The code that then gets written naturally reflects these norms and traditions, because people want to see on their computer as they can see in the book on the table in front of them.
  1 Comment
dpb on 11 Jan 2015
I agree there's a lot of the "what's in the book" direct implementation; perhaps that's even more so for those of us of a certain age for whom the only computer language was FORTRAN (yes, long before "Fortran") on punch cards with the inviolate 72 columns starting in column 7 rule.

Sign in to comment.

Image Analyst
Image Analyst on 11 Jan 2015
Here's how tutorial creator Doug Hull of the Mathworks views it. See #6 on, also #5 and the others.
John D'Errico
John D'Errico on 11 Jan 2015
I completely agree with Star here. Those spare parens and brackets make the code easier to read, at least for me. Others might find them an excessive use of characters. Whatever floats your boat...

Sign in to comment.

Iain on 12 Jan 2015
When it comes to making code readable,
scDSI (:, theta+1) = scRadius * [ cosd(theta); sind(theta); 0.0 ];
Is not as readable as:
scDSI(:, theta+1) = scRadius * [cosd(theta) sind(theta) 0.0]' ;
scDSI(:, theta+1) = [cosd(theta)
0.0] * scRadius;
Is better....
  1 Comment
dpb on 12 Jan 2015
I'd contend
scDSI(:, theta+1) = scRadius * [cosd(theta)
is "better" yet given that the multiplier is a constant.

Sign in to comment.


Find more on Entering Commands in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!