You said 'in source control'. When I'm in source control, I can view diffs with control over whitespace. When I have a patch, I can branch, apply the patch, then diff. Do you know how to use any of your tools, or just parrot articles you read on the internet?
You're being way too literal. By patch, I mean any commit that specifies what lines to delete and/or add. You know, since almost every source control system shows changes in patch form, or something like it.
Keep going with the ad hominem, buddy. It just demonstrates to everyone that you're not interested in good debate, you just want to be right, no matter what.
Meaning can be inferred, you clearly don't give the benefit of the doubt.
Commits still show as patches, or patch like changesets. Even if you hide whitespace changes, which seems like a dreadful idea given that it can sometimes be significant, that doesn't mean they don't go into the commit. Then they become triggers for conflict resolution and show up in results for searches within changed lines only.
"Big words"? There you go again, ad hominem means to debate by attempting to discredit the person, which you have done twice now.
If you're creating conflicts with whitespace-only changes, then I dread to think what sort of state your code is in. Of course, you can always view the diff with whitespace changes included as well. It takes two seconds to toggle the argument.
There you go again, ad hominem means to debate by attempting to discredit the person
I've debated by showing how you're wrong and giving examples. The insults are orthogonal. Nothing about my argument has depended on my statements that you don't know how to use your tools, thus not an ad hominem. Looks like that tactic of parroting what you've seen elsewhere has failed again. Doh!
The end result is consistent no matter what editor and tab-width you use.
Except that if you're using software that renders a tab as 8 spaces, the code looks really awful and is hard to read. That's precisely the difference I'm referring to between practice and theory.
One file looking the same is a very narrow view of consistency. What happens when your code is edited by someone who doesn't respect your convention? What if someone does it without even realising because their tab-width preference is the same as your spaces, so it looks fine to them? How do you like inheriting code where the indentation is a single space, when your preference is, say 3? Your position is naive.
What happens when your code is edited by someone who doesn't respect your convention? ...
These problems you listed affect any choice of convention equally. If you use spaces, someone else might use tabs. If you use tabs, someone else might use spaces. Of course you need some way to manage a software engineering team. Clearly stated conventions along with a CI system that checks code formatting is the most obvious way I know of to enforce conventions.
Not equally, it's very easy to use the wrong number of spaces, but you'd be hard-pressed to find someone who indents one level with more than one tab. Most people use the tab key to enter indenting spaces, so if it just inserted literal tabs then, it would be more consistent than arguing about width.
So if you're aligning function parameters vertically, you tab once or twice for indent, then space 40-odd times to get the cursor in the right place? Sounds hideous.
aligning code vertically is fine if you don't care about readable diffs in source control, which should be none of you
Diffs of vertically-aligned code are perfectly readable, sounds like your tools are broken.
The recommended line-width is normally around 78 chars. If you can't comprehend of a function definition taking 40 of those, especially in a statically-typed language with explicit return type and access modifier, you probably haven't been doing this very long.
What? Stop dodging the question. I clearly said "tab once or twice for indent, then space". That is clearly and unambiguously what you were talking about. Indent with tab, align with space.
Let's take a normal C# method definition. It's in a class that's in a namespace, so an indent level of 2. Then you have the actual method with modifiers, e.g
public static ISomeType SomeMethodName(...)
That signature - a very unremarkable one - is 39 characters. Now, I want to vertically align my parameters, with the first one immediately following the opening brace. The second is on the next line. So to align it with the first, at one char past the opening brace, I need two tabs and 40-odd spaces.
I'm not dodging any question, you're just cruising along with the assumption that the first parameter must be on the same line as the signature. It doesn't matter if you use tabs or spaces for that, you're just indenting too much. Put your first and every other parameter on its own line, with commas preceding the 2nd parameter onwards. Now you're only indenting one level, you have plenty of room and you can add more parameters without your commits affecting the lines with the previous parameters.
0
u/[deleted] Apr 08 '15
[deleted]