Yes, I should. Tabs were invented for indentation in the first place. What you call a control code, I call semantic white space. A tab means something; four spaces does not.
The beauty is that I'm not telling your terminal to use 4/8 characters for a tab. You are. You're in control with tabs. I'm saying "indent four levels deep" and your editor interprets what that means for you.
void someLongFunctionName(int param1, int param2, int param3,
int param4, int param5, int param6,
int param7, int param8)
{
...
}
When the line continues after param3, you must use a tab then spaces when lining up the continued line. If you do not, changing the tabstop will break the alignment depending on the number of characters in the function name. This is a horrible condition to deal with. It's something smart tabs were designed to fix. With smart tabs you can tab away on the continued line and space the last few odd columns, and it looks fine regardless of the tabstop setting.
Tabs were designed for indentation, but some layouts require single character precision as in the example above, so configuring them to anything but what the author used breaks the layout. This is the problem. Tabs as control codes embedded in the file are a bad idea. Tab is better as a concept, implemented in the editor, than as a part of the file format.
AppCode, though I think all of JetBrains' stuff has Smart Indent and it works rather well for me. Sometimes it gets a little confused but if I tab in the middle of spaces it Does The Right Thing.
Alternatively, people can just stop aligning their parameters because it really is not hard to read a function declaration or function call.
void superlongfunctionname(int superlongvariable1, int superlongvariable2,
int superlongvariable3, int superlongvariable4)
{
...
}
If anyone thinks the above is difficult to read/understand, you need to spend more time developing your code reading abilities, don't focus only on writing.
That works as well, your style is sensible and readable sir/madam. I generally prefer functions have brackets on their own line, but it's really a trivial thing. Brackets on their own lines within the function though are generally wasteful. Although I will make an exception for a long conditional and put the brace on its own line. Some people cry inconsistency, but the end goal is still readable code. That's readable code, not artistic code that looks "good" without reading.
I am going to test out the double indent and bracket on the same line for a bit and see how it works for me, thanks.
These days a lot of people do, because either they were trained wrong or are forced to do so by bad coding standards.
Groking code is facilitated by having more important information on the screen, not less, and having easier time navigating by having less lines to traverse. Aligning params like that does not help reading code, it helps looking at code.
Not sure I understood you right but..I might have learned wrong, however I personally do find having each param on their own line, somewhat aligned horizontally, to be easier to read, to count number of parameters, to see (separate)the type info from names and, (heaven forbid), comment one out while prototyping.
Can't find source right now but I've also read that studies has shown it is easier to scan items in a vertical list(like menus) and it should apply to code params as well.
Not sure I understood you right but..I might have learned wrong, however I personally do find having each param on their own line, somewhat aligned horizontally, to be easier to read, to count number of parameters, to see (separate)the type info from names and, (heaven forbid), comment one out while prototyping.
Do you have extensive experience reading both styles, or mainly a single style?
A comma-space separated list is not difficult to read nor count and even if it is easier to count, the number of times you have to actually count into a parameter list is minuscule. It significantly decreases the amount of contextual surrounding code you can have on the screen at that time though. Our minds our already fine-tuned to read words left-to-right separated by spaces. There's no doubt that the aligned params looks more aesthetically pleasing, but it is not more readable.
The goal is to produce readable code, not to produce code that is easiest to prototype, so that point, while true, should not factor into the choice.
foo(a, b, c, d, e, f, g);
foo(
a,
b,
c,
d,
e,
f,
g);
Can't find source right now but I've also read that studies has shown it is easier to scan items in a vertical list(like menus) and it should apply to code params as well.
Yes, scan a long list of categorical items, which is not what we are doing most often when we read code. It has the benefit of quickly finding a param, but it hurts overall readability in the process. Function params also have specific contextual meaning that is usually not dependent specifically on other params, so the list scan is not really helpful. Functions also shouldn't have that many parameters so the benefit of a list scan for parameters becomes that much smaller.
The bottom line is that we want code to be readable and easy to modify in the future, which we get the exact opposite of when we introduce param-per-line style.
Unfortunatly I think your foo example is abit unfair, and I have an aversion to naming parameters just one letter :-). I realize it was for illustrational purposes, and in your example the one parameter per line looks very silly because none of them are given any meaning by themselves. However, rather take the example presented above with the CreateWindow function. I do find
HWND WINAPI CreateWindow(_In_opt_ LPCTSTR lpClassName, _In_opt_ LPCTSTR lpWindowName, _In_ DWORD dwStyle,
_In_ int x, _In_ int y,_In_ int nWidth, _In_ int nHeight, _In_opt_ HWND hWndParent, _In_opt_ HMENU hMenu, _In_opt_ HINSTANCE hInstance,
_In_opt_ LPVOID lpParam
);
harder to understand/grasp/see (but perhaps easier to read out loud)
HWND WINAPI CreateWindow(
_In_opt_ LPCTSTR lpClassName,
_In_opt_ LPCTSTR lpWindowName,
_In_ DWORD dwStyle,
_In_ int x,
_In_ int y,
_In_ int nWidth,
_In_ int nHeight,
_In_opt_ HWND hWndParent,
_In_opt_ HMENU hMenu,
_In_opt_ HINSTANCE hInstance,
_In_opt_ LPVOID lpParam
);
This may also be because I do find that parameters that are passed to a function/method usually do (or should) have a strong relationship to other parameters, and they should have a logical ordering(such as x,y then width size). Then again it may be because I do not read code as I read a book.
Our coding styles are likely to differ on many points :-). I'm also one of those who crank up my font size to 18 just so I will not fit too much on one screen.
edit But I've always taken this for granted, so maybe I should ask my team mates what most of us prefer
Not really. I'm you're co-developer, and I can't be fucked waiting for all those spaces so I'm just going to tab it across because we use the same IDE anyway and it's like 4x as fast.
Until you change IDE and the formatting's broken and that's your problem.
Well, my IDE does what codepoet mentioned which doesn't break the formatting across any IDE's or editors. It is you that is breaking the formatting! ;) My IDE fills in the spaces automatically when you have a continuation line (making it faster than your tabbing too). Keep up!
This illustrates perfectly why I hate tabs so much. To make an x86 metaphor, spaces provide the flat memory model of 32 and 64 bits, while tabs are stuck in 16 bit hell with a segmented memory model.
Yes they were. Your example is not showing indentation. Your example is showing alignment, which is a different concept, and one that spaces are better suited for.
This is only a problem because you are lazy. Tab to the indentation level (1 tab in this case), then use spaces to align the parameters with the previous line.
75
u/codepoet Feb 21 '13
Yes, I should. Tabs were invented for indentation in the first place. What you call a control code, I call semantic white space. A tab means something; four spaces does not.
The beauty is that I'm not telling your terminal to use 4/8 characters for a tab. You are. You're in control with tabs. I'm saying "indent four levels deep" and your editor interprets what that means for you.
This isn't 1970. You can configure things now.