5 ms·

Interesting, but how do you know if you passed the column 80? how do you work when the coding standards mix tabs and spaces (like tab for indenting, spaces for

Interesting, but how do you know if you passed the column 80? how do you work when the coding standards mix tabs and spaces (like tab for indenting, spaces for multi-line aligning)?

hmottestad 13y ago
First off I'm a student. Though the last summer job I had people didn't really care that much. Tabs/spaces doesn't really matter much. 80 char width also never been a problem. If it makes sense to have it on a 150 char line, then so be it. If it makes sense to split it up, then do that. The only time I ran into length problems was when I was asked to print my code on A4 paper for an exam.
- alcuadrado 13y ago
  80 coloumns avoid that (and other) problems. mixing tabs and spaces is strange and IMO should be avoided, but it sometimes happen :( all-spaces FTW
VLM 13y ago
I don't use a proportional font like the OP but graphics art stuff like that is best handled by computer. For example if you do sysadmin scripts in perl and edit with vim and have perltidy installed, its more or less just (esc) :%! perltidy (enter) and it looks beautiful. Gave up on 80 columns a couple years ago. Haven't looked back much.
Stratoscope 13y ago
Those are coding standards designed for monospaced fonts. They work poorly with proportional fonts, but there is a simple solution: abandon those standards. With regard to indenting vs. column alignment, don't do column alignment. Code is an outline. It's not a spreadsheet. Column alignment is not beneficial in most cases, and it wreaks havoc with source control diffs. Is it really better to code like this: double someFunctionName( int index, // counts things SomeType secondParamWithStuff, // fancy object with stuff SomeLongerNamedType third ) // whatever instead of this: double someFunctionName( int index, // counts things SomeType secondParamWithStuff, // fancy object with stuff SomeLongerNamedType third // whatever ) Now sure, the second version may look a bit sloppy if you're used to the first, but it has several real advantages: * Much less horizontal eye movement * No eye tracking across wide swaths of whitespace * Changing one name doesn't require reformatting the whole thing * Since you don't have to reformat, it doesn't generate unrelated diffs * It works equally well in proportional or monospaced fonts Oddly enough, many years ago I switched to the second style, not because I was using a proportional font at the time, but because I was really tired of reformatting multiple lines of code just because I'd refactored one variable or type name. And then some time later I tried a proportional font. My code looked fine in the proportional font, and it was still just as readable in a monospaced font. WRT 80 columns or whatever your limit is, I just don't worry about that. I generally keep my lines quite a bit shorter than that, but if a particular piece of code is more readable with a longer line, I don't sweat it.
- jussij 13y ago
  > Code is an outline. It's not a spreadsheet. Column alignment is not beneficial in most cases But there are many cases where code works best as a spreadsheet. For example any time you need to initialise an array of structures, that is best viewed using a grid like pattern. > but because I was really tired of reformatting multiple lines of code just because I'd refactored one variable or type name. Any decent editor with smart indenting should eliminate most of that effort. Also if the editor is scriptable editor, it should be possible to create a simple script to semi-automate the task.
  - ShirtlessRod 13y ago
    > Also if the editor is scriptable editor, it should be possible to create a simple script to semi-automate the task. True, but why do it in the first place? Note that I'm not supporting proportional fonts here -- I much prefer fixed-width -- but I also don't like formatting function signatures like that.
    - jussij 13y ago
      > True, but why do it in the first place? For me, I prefer reading and editing vertically aligned code. Also I don't find it overly difficult to make sure everything is line up vertically.
      - ShirtlessRod 13y ago
        It's not difficult, it's just one more thing to have to do. Like most things, I think it really just boils down to an aesthetic preference, and it's usually up to whoever actually maintains the code anyway. :)
  - Stratoscope 13y ago
    > But there are many cases where code works best as a spreadsheet. Indeed, that's true, and I don't mean to be too much of a proportional font fanatic. Even if I try to avoid coding styles that require monospaced fonts to be readable, there are always cases where it helps to get a monospaced view of the code. One feature I really like in an editor is an easy way to switch between proportional and monospaced views. The best support I've seen for this is in Komodo [1]. Like many editors, Komodo supports multiple themes of font face/size/colorization/etc. What it does differently, though, is that each theme has two font selections, a proportional font and a monospaced one. So you can pick your favorite for each, and then choose whichever works best for the particular code you're looking at right now. Oddly enough, out of the box Komodo doesn't give you a keyboard shortcut to switch between proportional and monospaced, but it's easy enough to add a keyboard shortcut for this. (In the Key Bindings dialog, look for User Interface: Use Fixed/Proportional Font.) I have this set to Alt+O which is unused in a default Komodo installation on Windows, and it's easy to remember because "proportional/monospaced font" has a heck of a lot of "O"s in it. :-) But when I do use an editor that only offers monospaced fonts, it's not a terrible thing. I use your excellent Zeus IDE [2] for my Go coding and it's a pleasure to work with. Sure, I miss my proportional fonts, but having the integrated debugger and other goodies for Go makes it well worth it. [1] http://www.activestate.com/komodo-edit http://www.activestate.com/komodo-edit [2] http://www.zeusedit.com/ http://www.zeusedit.com/
sltkr 13y ago
Elastic tabstops [1] would work perfectly with proportional fonts. 1. http://nickgravgaard.com/elastictabstops/ http://nickgravgaard.com/elastictabstops/
- anonymous 13y ago
  One critique I have of elastic tabs is that you need to read the whole document to know how to lay out just what you see before you. That's not an issue with files up to a couple of thousand slocs, but I've had to work with 60ksloc autogenerated source files and waiting for one of those to be parsed and laid out would be a pain in the ass.

Interesting, but how do you know if you passed the column 80? how do you work when the coding standards mix tabs and spaces (like tab for indenting, spaces for multi-line aligning)?

hmottestad 13y ago

First off I'm a student. Though the last summer job I had people didn't really care that much. Tabs/spaces doesn't really matter much. 80 char width also never been a problem. If it makes sense to have it on a 150 char line, then so be it. If it makes sense to split it up, then do that. The only time I ran into length problems was when I was asked to print my code on A4 paper for an exam.

alcuadrado 13y ago
80 coloumns avoid that (and other) problems. mixing tabs and spaces is strange and IMO should be avoided, but it sometimes happen :( all-spaces FTW

VLM 13y ago

I don't use a proportional font like the OP but graphics art stuff like that is best handled by computer. For example if you do sysadmin scripts in perl and edit with vim and have perltidy installed, its more or less just (esc) :%! perltidy (enter) and it looks beautiful. Gave up on 80 columns a couple years ago. Haven't looked back much.

Stratoscope 13y ago

Those are coding standards designed for monospaced fonts. They work poorly with proportional fonts, but there is a simple solution: abandon those standards. With regard to indenting vs. column alignment, don't do column alignment. Code is an outline. It's not a spreadsheet. Column alignment is not beneficial in most cases, and it wreaks havoc with source control diffs. Is it really better to code like this: double someFunctionName( int index, // counts things SomeType secondParamWithStuff, // fancy object with stuff SomeLongerNamedType third ) // whatever instead of this: double someFunctionName( int index, // counts things SomeType secondParamWithStuff, // fancy object with stuff SomeLongerNamedType third // whatever ) Now sure, the second version may look a bit sloppy if you're used to the first, but it has several real advantages: * Much less horizontal eye movement * No eye tracking across wide swaths of whitespace * Changing one name doesn't require reformatting the whole thing * Since you don't have to reformat, it doesn't generate unrelated diffs * It works equally well in proportional or monospaced fonts Oddly enough, many years ago I switched to the second style, not because I was using a proportional font at the time, but because I was really tired of reformatting multiple lines of code just because I'd refactored one variable or type name. And then some time later I tried a proportional font. My code looked fine in the proportional font, and it was still just as readable in a monospaced font. WRT 80 columns or whatever your limit is, I just don't worry about that. I generally keep my lines quite a bit shorter than that, but if a particular piece of code is more readable with a longer line, I don't sweat it.

jussij 13y ago
> Code is an outline. It's not a spreadsheet. Column alignment is not beneficial in most cases But there are many cases where code works best as a spreadsheet. For example any time you need to initialise an array of structures, that is best viewed using a grid like pattern. > but because I was really tired of reformatting multiple lines of code just because I'd refactored one variable or type name. Any decent editor with smart indenting should eliminate most of that effort. Also if the editor is scriptable editor, it should be possible to create a simple script to semi-automate the task.
- ShirtlessRod 13y ago
  > Also if the editor is scriptable editor, it should be possible to create a simple script to semi-automate the task. True, but why do it in the first place? Note that I'm not supporting proportional fonts here -- I much prefer fixed-width -- but I also don't like formatting function signatures like that.
  - jussij 13y ago
    > True, but why do it in the first place? For me, I prefer reading and editing vertically aligned code. Also I don't find it overly difficult to make sure everything is line up vertically.
    - ShirtlessRod 13y ago
      It's not difficult, it's just one more thing to have to do. Like most things, I think it really just boils down to an aesthetic preference, and it's usually up to whoever actually maintains the code anyway. :)
- Stratoscope 13y ago
  > But there are many cases where code works best as a spreadsheet. Indeed, that's true, and I don't mean to be too much of a proportional font fanatic. Even if I try to avoid coding styles that require monospaced fonts to be readable, there are always cases where it helps to get a monospaced view of the code. One feature I really like in an editor is an easy way to switch between proportional and monospaced views. The best support I've seen for this is in Komodo [1]. Like many editors, Komodo supports multiple themes of font face/size/colorization/etc. What it does differently, though, is that each theme has two font selections, a proportional font and a monospaced one. So you can pick your favorite for each, and then choose whichever works best for the particular code you're looking at right now. Oddly enough, out of the box Komodo doesn't give you a keyboard shortcut to switch between proportional and monospaced, but it's easy enough to add a keyboard shortcut for this. (In the Key Bindings dialog, look for User Interface: Use Fixed/Proportional Font.) I have this set to Alt+O which is unused in a default Komodo installation on Windows, and it's easy to remember because "proportional/monospaced font" has a heck of a lot of "O"s in it. :-) But when I do use an editor that only offers monospaced fonts, it's not a terrible thing. I use your excellent Zeus IDE [2] for my Go coding and it's a pleasure to work with. Sure, I miss my proportional fonts, but having the integrated debugger and other goodies for Go makes it well worth it. [1] http://www.activestate.com/komodo-edit http://www.activestate.com/komodo-edit [2] http://www.zeusedit.com/ http://www.zeusedit.com/

sltkr 13y ago

Elastic tabstops [1] would work perfectly with proportional fonts. 1. http://nickgravgaard.com/elastictabstops/ http://nickgravgaard.com/elastictabstops/

anonymous 13y ago
One critique I have of elastic tabs is that you need to read the whole document to know how to lay out just what you see before you. That's not an issue with files up to a couple of thousand slocs, but I've had to work with 60ksloc autogenerated source files and waiting for one of those to be parsed and laid out would be a pain in the ass.