I thought it is 5 at the start for FORTRAN line numbers (loop labels), the 6th column marks continuation lines, and the 8 at the end are ignored by FORTRAN and usually used for a card sequence number. So more like 66 columns for actual code.
Writing C with 8 column tabs for indentation means code is usually less than 72 columns wide.
Yes, that's more correct than my half-remembered summary. It's a very long time since I wrote ruler-edge FORTRAN, as it has suppored free-format since the 1990 Fortran standard!
I tend to think nowadays that tabs in general are EBW - exim's code is written to this rule. However a lot of code I have worked on in the recent past follows BSD/Linux kernel normal form and it's still my default.
I use the tab *key* for indent, but emacs converts it into the right number of spaces for me (usually) and incidentally makes it easier to spot when I've got the code wrong.
You can customize indent-tabs-mode to nil to avoid it inserting actual tab characters. But you won't thank me for this if ever you edit the few file formats that require tabs (and that Emacs doesn't have any kind of exception for which I think includes makefiles); in that case your best bet is probably to set it locally from mode hooks.
I've not found I had to do anything to make it correctly indent code when I've been writing Perl, perhaps that's the default for perl-mode? I only find it gets it wrong if I have a regexp containing some sort of unmatched quote or opening bracket, in which case I end up having to append a comment closing it again or it refuses to line up properly :)
Oh, it should certainly correctly indent by default. indent-tabs-mode determines whether it will insert only spaces or whether it will use tab characters (i.e. ASCII 0x09) to replace runs of spaces - which makes the file smaller but also makes the layout ambiguous (and I find can make navigation trickier as the cursor likes to go to one end of the tab or the other rather than in the middle).
No hard limit, but I tend to try and break up lines longer than about 120-140 chars. I'd better stress I'm not writing code that other people have to maintain.
Common sense is 80 columns for prose, because anything longer makes it difficult to easily read from one line to the next.
Code, however, (a) does not fit into dense paragraphs, and (b) often comes with heavy indentation. I used to try and fit it into eighty columns, and ended up with the code more difficult to read, as a result. I'd say 132 columns is a reasonable optimum on this scale.
I don't have difficulty reading prose which is significantly wider than 80 characters, but I'm used to reading solid prose on a 1680x1050 screen with small fonts.
I disagree, but then my terminals and editors are typically around 140 columns wide.
Common sense is whatever is right for the project you're in. Some projects use tabs, define tabs to be eight characters, require 80 column limits, and complain when you use acronyms for your variable names because they're not clear enough.
Some projects you end up with huge lines like the example in the poll, and that sucks too.
Mostly I *try* to stick to around 80 columns, but I won't arbitrarily wrap something which would exceed that by less than 20 columns unless it doesn't affect readability to me.
Anything over 80 columns better have a reasonable excuse (eg it's using a C++ interface to a Java framework, like what I'm doing right now). Anything over 132 columns will result in Paddington Bear Hard Stares.
I admit my tabs are usually 3 or 4 spaces, so I do go over 80 columns sometimes, but I try to avoid going much over 100 or 132 because it starts to get unreadable. I find a 1 or 2 space indent just a bit too small to follow.
Even at 4 space indents breaching 80 columns is often a hint to use a subroutine. (Indeed IIRC there are those who advocate using 8 space indents precisely because it forces you to break things up into subroutines.)
It's possibly true, and looking at a random example of a bit of my code I could actually fix most of the long lines simply by splitting them in two without much loss of readability, and I have used subroutines in some places so none of the long lines are caused by indenting off into oblivion.
I've got some rather horridly long regexps that I'm not sure I could make shorter though. (Although actually I can spot a way to lose about 8 characters off the worst instance, *ahem*, which would at least get me under 100 characters). Someone better at regexps than me might well be able to improve it though.
And some print statements where I'm printing a c. 80 character line of output and it seems daft to create a variable to put it in just to make the code narrower, when no-one who's going to be reading this code is likely to be doing it restricted to 80 cols, those are only about 90 cols.
My worst lines seem to be 123 cols, including a comment on the end of the line. And I think those are getting a bit too long. I shall do better in future.
Basically a 100 column emacs window is just a nice size though :)
If you're using Perl then you have the option to break up regexps over multiple lines, insert non-semantic whitespace, comments, etc. See “/x modifier” in man/perldoc perlre. That said I don't use this myself (not that I write all that many monster regexps).
Anything between about 80 and about 132 here; a hard limit isn't a useful requirement for most of the environments we work in. As ever, readability is more important than slavishly fitting lines inside some arbitrary limit; spilling a few characters over isn't going to summon nasal demons.
[Although I may need to consult the manual for EDIT /TPU on VMS to find out if there's some way to actually work on lines that have been marked as extending past the edge of the screen... Ugh. Sticking to an 80 character limit makes sense there!]
In code I originate myself, 80 columns (though I allow myself the occasional insanely long line if breaking it up would somehow manage to be even uglier). I like to fill a high-resolution display with lots of 80-column-wide terminals and editors rather than maximising one window over the whole thing, and even if I didn't do that I'd like to think I'd have some sympathy for other people reading my code who did.
At work, I maintain (among other things) a program which was written by somebody with a wider editor window than that, and so far it has seemed easier to expand my own editor window than to do a big reformatting checkin. (Particularly given that his code wouldn't be very easy to reformat to 80 columns, since he did tend to draw all his identifiers from a naming scheme of which your last option is only a mild exaggeration.)
My monitor's resolution is such that two 80 col windows leave 37 columns spare (and that's including the window furniture). So an 80 column terminal and a 100 column emacs fit very nicely together.
And a lot of the stuff I'm working with is log files with much longer lines than that, so I'm out of the habit of assuming things are narrow, unless I'm working in a terminal. I should try and bear other people in mind a bit more though.
In my case, it's coming from a glass teletype background, where the tube screens were 80 chars wide, and not resizable. And 80 column punch cards before that...
Unix (as implemented in practice) hasn't forced 80 columns for decades. But it's desirable to get multiple files (or multiple views on the same file) across the screen, and agreeing a limit makes that a great deal more practical.
[X] It is vital that polls including calls to DoorReleaseRemoteControlEscutcheonPlateBezelFactoryFactory.CreateDoorReleaseRemoteControlEscutcheonPlateBezelFactory be placed under an lj-cut.
This needs a follow-up poll on the right way to indent code:
[ ] 8 unit wide hard tabs only [ ] 4 unit wide hard tabs only [ ] space-based soft tabs at 8 units only [ ] space-based soft tabs at 4 units only [ ] an ungodly mixture of 8 unit wide hard tabs and spaces [ ] whatever M-x c-indent-command thinks is right [ ] I only write lisp
A Brief, Incomplete ... History of Programming Languages (http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html) "1940s - Various "computers" are "programmed" using direct wiring and switches. Engineers do this in order to avoid the tabs vs spaces debate."
(And I still think sticking to at least not often going much over 80 helps more than it reduces readability. But I'll settle for 132 as a hard limit.)
I think unless it's obviously insane, it doesn't matter too much as long as everyone does the same thing (or everyone does something that can be munged into the same thing by the VCS). I once found a piece of code that variously used 2, 3, 4, 5, 6, and 8 spaces for indenting. That was fun to understand.
Wrapping at 80 generally feels artificially narrow to me -- usually my first act with an 80-column anything is to make it wider. Usually I just wrap at however wide my emacs happens to be, which is usually somewhere between 100 and 132 columns.
I think 80-wrapping code like this:
I almost always try for 80 to avoid causing other people problems reading the code (and since I find overly deep indentation to be a sign of other problems, see above), although in reality I sometimes forget since for various reasons I have got into the habit of using maximised terminal windows.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2009-05-11 03:13 pm (UTC)(no subject)
Date: 2009-05-11 03:47 pm (UTC)(no subject)
Date: 2009-05-11 03:56 pm (UTC)Writing C with 8 column tabs for indentation means code is usually less than 72 columns wide.
(no subject)
Date: 2009-05-11 04:01 pm (UTC)And using tab for indent is evil, bad, and wrong.
(no subject)
Date: 2009-05-11 04:06 pm (UTC)(no subject)
Date: 2009-05-11 04:13 pm (UTC)(no subject)
Date: 2009-05-11 04:15 pm (UTC)(no subject)
Date: 2009-05-11 08:05 pm (UTC)(no subject)
Date: 2009-05-12 11:28 am (UTC)(no subject)
Date: 2009-05-12 11:36 am (UTC)(no subject)
Date: 2009-05-11 04:54 pm (UTC)Took me a whole day to spot I'd wandered into col73 once.
(no subject)
Date: 2009-05-11 03:14 pm (UTC)(no subject)
Date: 2009-05-11 03:14 pm (UTC)Instead it should be "Common sense" wrt. line length IMO.
(no subject)
Date: 2009-05-11 03:57 pm (UTC)(no subject)
Date: 2009-05-11 04:35 pm (UTC)Code, however, (a) does not fit into dense paragraphs, and (b) often comes with heavy indentation. I used to try and fit it into eighty columns, and ended up with the code more difficult to read, as a result. I'd say 132 columns is a reasonable optimum on this scale.
(no subject)
Date: 2009-05-11 04:37 pm (UTC)If your code marches off the right of your screen then you're doing it wrong.
(no subject)
Date: 2009-05-13 08:24 am (UTC)(no subject)
Date: 2009-05-13 08:23 am (UTC)Common sense is whatever is right for the project you're in. Some projects use tabs, define tabs to be eight characters, require 80 column limits, and complain when you use acronyms for your variable names because they're not clear enough.
Some projects you end up with huge lines like the example in the poll, and that sucks too.
Mostly I *try* to stick to around 80 columns, but I won't arbitrarily wrap something which would exceed that by less than 20 columns unless it doesn't affect readability to me.
(no subject)
Date: 2009-05-11 03:23 pm (UTC)(no subject)
Date: 2009-05-11 03:49 pm (UTC)(no subject)
Date: 2009-05-11 04:12 pm (UTC)(no subject)
Date: 2009-05-11 08:03 pm (UTC)(no subject)
Date: 2009-05-12 08:53 am (UTC)I've got some rather horridly long regexps that I'm not sure I could make shorter though. (Although actually I can spot a way to lose about 8 characters off the worst instance, *ahem*, which would at least get me under 100 characters). Someone better at regexps than me might well be able to improve it though.
And some print statements where I'm printing a c. 80 character line of output and it seems daft to create a variable to put it in just to make the code narrower, when no-one who's going to be reading this code is likely to be doing it restricted to 80 cols, those are only about 90 cols.
My worst lines seem to be 123 cols, including a comment on the end of the line. And I think those are getting a bit too long. I shall do better in future.
Basically a 100 column emacs window is just a nice size though :)
(no subject)
Date: 2009-05-12 10:28 am (UTC)(no subject)
Date: 2009-05-11 04:24 pm (UTC)[Although I may need to consult the manual for EDIT /TPU on VMS to find out if there's some way to actually work on lines that have been marked as extending past the edge of the screen... Ugh. Sticking to an 80 character limit makes sense there!]
(no subject)
Date: 2009-05-11 04:39 pm (UTC)At work, I maintain (among other things) a program which was written by somebody with a wider editor window than that, and so far it has seemed easier to expand my own editor window than to do a big reformatting checkin. (Particularly given that his code wouldn't be very easy to reformat to 80 columns, since he did tend to draw all his identifiers from a naming scheme of which your last option is only a mild exaggeration.)
(no subject)
Date: 2009-05-12 08:55 am (UTC)And a lot of the stuff I'm working with is log files with much longer lines than that, so I'm out of the habit of assuming things are narrow, unless I'm working in a terminal. I should try and bear other people in mind a bit more though.
(no subject)
Date: 2009-05-11 04:42 pm (UTC)(no subject)
Date: 2009-05-11 06:28 pm (UTC)(no subject)
Date: 2009-05-11 08:10 pm (UTC)(no subject)
Date: 2009-05-11 04:58 pm (UTC)(no subject)
Date: 2009-05-11 05:45 pm (UTC)[X] It is vital that polls including calls to DoorReleaseRemoteControlEscutcheonPlateBezelFactoryFactory.CreateDoorReleaseRemoteControlEscutcheonPlateBezelFactory be placed under an lj-cut.
(no subject)
Date: 2009-05-11 05:51 pm (UTC)(no subject)
Date: 2009-05-11 06:00 pm (UTC)(no subject)
Date: 2009-05-11 08:12 pm (UTC)(no subject)
Date: 2009-05-11 06:12 pm (UTC)(no subject)
Date: 2009-05-11 06:38 pm (UTC)(no subject)
Date: 2009-05-11 06:15 pm (UTC)(no subject)
Date: 2009-05-11 07:06 pm (UTC)[ ] 8 unit wide hard tabs only
[ ] 4 unit wide hard tabs only
[ ] space-based soft tabs at 8 units only
[ ] space-based soft tabs at 4 units only
[ ] an ungodly mixture of 8 unit wide hard tabs and spaces
[ ] whatever M-x c-indent-command thinks is right
[ ] I only write lisp
(no subject)
Date: 2009-05-11 07:47 pm (UTC)(no subject)
Date: 2009-05-11 09:58 pm (UTC)"1940s - Various "computers" are "programmed" using direct wiring and switches. Engineers do this in order to avoid the tabs vs spaces debate."
(And I still think sticking to at least not often going much over 80 helps more than it reduces readability. But I'll settle for 132 as a hard limit.)
(no subject)
Date: 2009-05-11 10:07 pm (UTC)(no subject)
Date: 2009-05-12 11:42 am (UTC)(no subject)
Date: 2009-05-12 12:00 pm (UTC)(no subject)
Date: 2009-05-11 08:04 pm (UTC)hits = (find_next_bp_hit('INSTR_EXEC', None, self.swbps | self.hwbps, begints, endts, term), find_next_bp_hit('MEM_WRITE', 'watch', self.writewps | self.accesswps, begints, endts, term), find_next_bp_hit('MEM_READ', 'watch', self.readwps | self.accesswps, begints, endts, term), scan_terminator(begints, endts, term))would hurt its readability somewhat, which is why I'm not much in favour of such a low width.(no subject)
Date: 2009-05-11 08:23 pm (UTC)(no subject)
Date: 2009-05-12 08:58 am (UTC)(Seriously, I agree it would hurt it to wrap it at 80)
(no subject)
Date: 2009-05-15 11:39 pm (UTC)