| Rev | Author | # | Line |
|---|---|---|---|
| 7 | AristotlePagaltzis | 1 | !!! PerryLorier and his ReligiousWar |
| 1 | PerryLorier | 2 | |
| 13 | AristotlePagaltzis | 3 | Tabs should be 8 characters and no correspondance shall be entered into. While that's stupidly wide, at least it's a standard. There is absolutely nothing worse than opening a file and having it look like it was formatted by a two year old chimpanzee on crack. |
| 1 | PerryLorier | 4 | |
| 7 | AristotlePagaltzis | 5 | !! But vim/emacs support mode lines so you can see which tab width you use! |
| 1 | PerryLorier | 6 | |
| 13 | AristotlePagaltzis | 7 | Except: |
| 8 | * They don't agree on the syntax, so you need two sets of modelines, one for each application. | ||
| 15 | AristotlePagaltzis | 9 | * <tt>grep</tt>/<tt>patch</tt>/<tt>diff</tt>/<tt>sed</tt>/<tt>lpr</tt>/<tt>less</tt> don't read modelines. |
| 1 | PerryLorier | 10 | |
| 13 | AristotlePagaltzis | 11 | !! You can run things through a preprocessor to convert tabs to the correct number of spaces! |
| 1 | PerryLorier | 12 | |
| 13 | AristotlePagaltzis | 13 | A converted diff does not apply as a proper patch anymore. A converted MakeFile bombs out due to a "missing delimiter". A converted <tt>sendmail.cf</tt> means no mail is delivered. |
| 1 | PerryLorier | 14 | |
| 7 | AristotlePagaltzis | 15 | !! You can tell [Vim]/[Emacs]/etc to always expand tabs to spaces |
| 1 | PerryLorier | 16 | |
| 7 | AristotlePagaltzis | 17 | Some people may tell you to do something like |
| 4 | SamJansen | 18 | |
| 13 | AristotlePagaltzis | 19 | <verbatim> |
| 20 | :set tabstop=8 | ||
| 21 | :set shiftwidth=4 | ||
| 22 | </verbatim> | ||
| 4 | SamJansen | 23 | |
| 11 | AristotlePagaltzis | 24 | in [Vim] (and analogous in [Emacs]). Backspace for unindent doesn't work anymore then. You remove one space, not one tab. |
| 25 | |||
| 13 | AristotlePagaltzis | 26 | ''Please see [Converting tabs to spaces|http://vim.sourceforge.net/tips/tip.php?tip_id=12] which is a little more optimistic!'' —Ben Fowler |
| 7 | AristotlePagaltzis | 27 | |
| 28 | !! But they push my code too far to the right | ||
| 29 | |||
| 30 | Then your logic is too complicated. Break it into another function to simplify it. | ||
| 31 | |||
| 32 | %%% | ||
| 33 | |||
| 34 | The correct answer is to use 8 character tabs. Sure they are wider than they need to be, but they ''work''. Anyone who tries to tell you that tabs should be whatever else they feel like (2? 4? 5? 6?) needs to be shot. Especially if they ever think that their code is going to be viewed by anyone else, so unless you are writing a proprietary program and never planning on giving the code away or ever showing it to anyone, don't change the tab size. | ||
| 5 | JohnMcPherson | 35 | |
| 13 | AristotlePagaltzis | 36 | Of course, if everyone just used [Python] then it wouldn't matter. |
| 37 | |||
| 7 | AristotlePagaltzis | 38 | |
| 8 | AristotlePagaltzis | 39 | !!! Meanwhile, AristotlePagaltzis rests in nirvana |
| 7 | AristotlePagaltzis | 40 | |
| 41 | You can use 4 character tabs and feel fine all along. More importantly, so will the people who open your files. | ||
| 42 | |||
| 43 | The key to this state of mind is simple: __''don't use tabs ANYWHERE but the beginning of the line!!''__ | ||
| 44 | |||
| 45 | Well, people ''can'' throw a monkey wrench in this scheme if they use overly smrt(sic) editor( setting)s so tabs are used for 8 character gaps and spaces create smaller indentations. Unfortunately, way too many people think this is a good idea and way too many tools support and even suggest this style. This is utterly stupid. | ||
| 46 | |||
| 47 | __ONLY use tabs to indent. %%% ONLY use tabs at the beginning of a line. %%% ONLY use spaces to line up things in the middle of a block.__ | ||
| 48 | |||
| 49 | Then you can choose your tab width whichever way you like and noone will ever be the wiser from looking at your files. | ||
| 50 | |||
| 9 | PerryLorier | 51 | ''While this sounds fine, I've never seen it work in practise :( -- PerryLorier'' |
| 13 | AristotlePagaltzis | 52 | |
| 53 | |||
| 54 | !!! Unbeknownst to many, Nick Gravgaard sets out to solve the problem once and for all | ||
| 55 | |||
| 56 | In his [Elastic tabstops | http://nickgravgaard.com/elastictabstops/] article, he puts forth: | ||
| 57 | |||
| 58 | > Using spaces to align columns is obviously a kludge, but tabs as they stand now are broken. | ||
| 59 | > | ||
| 60 | > !! The solution - tabstops that expand or shrink to fit their contents | ||
| 61 | > | ||
| 62 | > For as long as we continue to define each tabstop as being a multiple of N characters we will never be able to solve this problem satisfactorily. The problem is that we're using tabs and spaces to format text for aesthetic reasons rather than treating them semantically – tabs are for indenting and aligning text, spaces are for separating keywords. The solution then is to redefine how tabs are interpreted by the text editor. Rather than saying that a tab character (a "hard tab") will move the cursor until the cursor's position is a multiple of N characters, we should say that a tab character is a delimiter between table cells in a similar manner to how they're used in tab separated value (TSV) files. | ||
| 63 | |||
| 14 | DanielLawson | 64 | Of course, the question is when (if ever) <tt>grep</tt>/<tt>patch</tt>/<tt>diff</tt>/<tt>sed</tt>/<tt>lpr</tt>/<tt>less</tt> would be taught to follow this approach… |
lib/blame.php:177: Warning: Invalid argument supplied for foreach() (...repeated 4 times)