Thu 13 Dec 2012
Things We Can’t Agree On… and a Few Decisions I’m Making to Solve Problems
Posted by Dan H under Code Editors, Programming
[3] Comments
The following is a list of things that the world could not agree on:
- The metric system is better than the English system we currently use (although I kind of like liquid measurements because it’s like they’re in powers of two).
- We should drive on the right side of the road, from the left side of the car.
- We can’t agree whether or not to have am and pm. Here in the U.S. we tend to refer to 24-hour time as “military time”, but I believe this is the standard in much of Europe.
- We can’t agree whether or not the day of the month, or the month itself comes first when listing the date. Again, in the United States the military behaves differently than the civilian world, but other countries do it differently as well.
- How to keep the music that was on a TV show in the actual TV show when it goes to DVD. I have over dated myself here a bit, I was thinking more of Miami Vice, but it appears it was eventually released to DVD. I never bought it, but those occasional Saturday afternoons when there’s a marathon of it on some basic cable channel, I enjoy several episodes while I procrastinate.
The things the world doesn’t agree on that annoy me, therefore making them by far the most annoying things the world does not agree on.
- New line characters. With the Mac’s “Unixification”, I believe we’ve moved from 3 formats to two, but WHY!?!? I believe one standard is quite enough, and since it uses fewer characters, we shall use the Unix standard. I’m fixing this, right now. From here on, lines end with 0xA. If you have old text files that wind up with extra characters, there are several things you can do. I suggest that you CHANGE them. Buy a copy of SlickEdit, and if you can’t figure out how to change them, one of the people in our support department will be proud to help you.
- File system case sensitivity. Case sensitive on UNIX, case insensitive/case preserving on Windows. AND Mac. And you could possibly have different file systems on UNIX that are case preserving, so that’s always a possibility. I’ll make this decision too: case insensitive/case preserving. OS and file system vendors, take note. If you’re on UNIX and have separate files, one named “LS” and one as “ls”, I suggest that you CHANGE them first, then comment on this post explaining why you would ever have done such a thing on purpose.
- Indent levels. Some people say 3. Some people say 4. Occasionally it’s 2. I’ll make this very simple: it’s 3. Make a note of it. If you’re using a 2, 4, 5, or some number other than 3, stop explaining why you prefer that number, and CHANGE it.
- If the language you are using enforces a certain indent, I’m not talking to you.
- If you are in your basement wearing a tinfoil hat developing another language that you think will solve the issues with all the ones available, and your language will enforce a certain indent level, make it 3. That is now the standard.
- Stop it. There are 4,397,531 computer languages. Yours will not solve all the other problems. It will have it’s own share.
- If you are in your basement wearing a tinfoil hat developing another language that you think will solve the issues with all the ones available, and your language will enforce a certain indent level, make it 3. That is now the standard.
- If the language you are using enforces a certain indent, I’m not talking to you.
- Tabs. Some people like to use tabs to indent, and have them match the indent amount. Some people like to set indent to one value (it had better be 3), and then set tabs to a larger number (maybe 8), so that it compresses the file somewhat. So on a line that is indented four times, you get one tab and 4 spaces, thus saving 7 bytes. So, when should you use tabs? NEVER. Tabs have NO place in source code. You don’t need to save the space. Attempting to save space cost us a lot of time and money with the whole Y2K 2-digit year fiasco. Here is a 1TB hard drive for $60. Buy two and use all the spaces you need. If you need to compress the leading whitespace in your code, you’re doing it wrong. SlickEdit it has a nifty feature to help you convert your tabs to spaces (Edit>Other>Tabs to Spaces). Get to work.
If you’d like to wait until after the holidays to implement these changes, I understand. If you’re waiting until after December 21st to see if you should waste your time in case the world ends because the Mayan calendar stopped there: they probably just stopped there. They probably just took it out a couple thousand years and said “that’ll do”.
December 27th, 2012 at 3:10 pm
I used to believe that the cr/lf line ending made more sense than the UNIX lf line ending (I grew up with printers that actually needed both cr and lf to get a new line). I’ve since come around to your viewpoint. I wish there was some possibility that the Windows world could switch over, but I believe that to be hopeless. I think we’re stuck with two kinds of line endings – it’s more likely that UNIX programs will become more tolerant of cr/lf line endings.
I used to agree with you about using spaces over tabs (but what’s up with an indent of 3? Everyone knows that 4 is the proper indent size – not too big and not too small). However, I’ve moved to align myself with people who argue for using tabs for indents only at the start of a line, then use spaces to attempt to align things after the first non-whitespace token on a line. Tabs within a line remain evil. Unfortunately, I don’t think many editors support this scheme in a first-class manner yet (ie., when pressing the tab key inserting a tab character only if before the first token on the line, insert spaces otherwise). And yes – space savings arguments are irrelevant today.
Something should be done about UNIX make syntax requiring tabs instead of spaces for certain semantics. I don’t know what kind of backwards compatibility issues removing that quirk would have, but Microsoft’s nmake gets by without caring whether the whitespace is used is a tab or not; it’s **insane** that UNIX make does.
As noted in “The Art of Unix Programming” (2003):
======================
No discussion of make(1) would be complete without an acknowledgement that it includes one of the worst design botches in the history of Unix. The use of tab characters as a required leader for command lines associated with a production means that the interpretation of a makefile can change drastically on the basis of invisible differences in whitespace. It is a matter of record that the original author of make realized this was an error early on, but felt he could not change it; after all, at that point he already had twelve users…
======================
And in an earlier edition (?):
======================
Why the tab in column 1? Yacc was new, Lex was brand new. I hadn’t tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn’t want to screw up my embedded base.
The rest, sadly, is history.
–
Stuart Feldman
======================
January 2nd, 2013 at 9:55 pm
I actually highly prefer the use of tabs (parsed to 4 spaces). It allows for easier editing. For example, will return to the column before the tab instead of having to delete four times. When you are editing files for many hours, this matters (as does a good coding style enforcement. Not everyone can write good code, but everyone should be able to write nice looking code at least).
Also, another Windows change would be to allow file names such as , i.e. no characters before the ‘.’. I am tired of having to go to msys to rename a file. Actually, I also don’t like Unix files without a prefix, but I understand their purpose.
I would also like the standard makefile to have an extension, such as makefile.mak (so I don’t have to have a ‘-f makefile.mak’). With a gui, I either have to right-click, open with or drag the file to my editor (or of course have it in my project).
Also, regarding line endings, why does Microsoft’s notepad basically reject anything but CRLF? If I use someone else’s computer (without SlickEdit of course), it is another nuisance.
January 2nd, 2013 at 9:58 pm
Whoops. I had some embedded tags in my last post.
I actually highly prefer the use of tabs (parsed to 4 spaces). It allows for easier editing. For example, ‘tab”tab”delete’ will return to the column before the tab instead of having to delete four times. When you are editing files for many hours, this matters (as does a good coding style enforcement. Not everyone can write good code, but everyone should be able to write nice looking code at least).
Also, another Windows change would be to allow file names such as ‘.ext’, i.e. no characters before the ‘.’. I am tired of having to go to msys to rename a file.
I would also like the standard makefile to have an extension, such as makefile.mak (so I don’t have to have a ‘-f makefile.mak’). With a gui, I either have to right-click, open with or drag the file to my editor (or of course have it in my project).
Also, regarding line endings, why does Microsoft’s notepad basically reject anything but CRLF? If I use someone else’s computer (without SlickEdit of course), it is another nuisance.