I started using the Lightning calendar add-on with the Thunderbird email client a few weeks ago, and have been wondering what the "CW" stood for in its date display.
Country Western?
Conventional Wisdom?
Used Google search and after going through a few search terms that either gave me too much or too little, I used "calendar CW lightning," which turned up this:
https://addons.mozilla.org/en-US/thunderbird/discussions/comments.php?DiscussionID=7662&page=1#Item_0
Ah, "Current Week!"
... and today's rant...
If I had time, I'd love to work on the Thunderbird text editor. I've gotten to the point where (if I'm going to use any formatting) I just compose my emails in Word, paste them into Thunderbird and then clean up as necessary. I do this because I have not yet been able to figure out how Thunderbird stores its formatting, and I can't find any way to make the "markup" visible. Is this because Thunderbird uses some low-grade Microsoft editing control, or some other reason? (Not that the editor in OutLook Express, or whatever its current name is, is much better...)
Tuesday, April 8, 2008
Friday, April 4, 2008
Maximum Method Magnitude
While I was roughing out a series of coding standards for the company I currently work at, I decided to quantify what I mean by "a method that is too long." I prefer to have methods (and functions, for the non-object-oriented among you, or you functional programmers) that I can see all at once. I don't like to scroll up and down (or left and right) to see the whole method. I therefore decided to quantify how much I could see on my screen at once so I could put some specific numbers in the standard.
Note that this restriction is relaxed for methods that are case statements with many similar, small cases, or other simple and repetitive structures. Since these are more "data"-like than "code"-like, having to scroll up and down doesn't interrupt my flow of thought as much as with regular code.
I currently have a Dell flat-screen that I measure at 22" (559 mm) visible diagonal size (regardless of what the Dell sales literature says...). I run it at its default resolution (1680 horizonally by 1050 vertically). I have a few icons on my desktop on the left (heavy use) and right (lighter use), so that reduces my available screen size a bit. I also like to leave room at the bottom of the screen for the taskbar.
I bounce back and forth between three editors, my old standby Epsilon, the Microsoft Visual Studio Editor and Eclipse.
I run Epsilon at 8-point Courier New, which gives me approximately 60 lines vertically and 200 characters horizontally. I spend more time in this editor than the others, so I've spent more time getting it to settings that work for me.
I never changed the default settings for Visual Studio. When I configure it as I usually work (one column of panes on the right), I get about 45 lines vertically and 150 characters horizontally. Note that this is reduced during debugging, because more panes appear. Tools, Options, Environment, Fonts and Colors tells me that I'm using 10-point Courier New.
I also never changed with the font settings in Eclipse. Preferences, General, Appearance, Colors and Fonts tells me that I'm using 10-point Courier New. This gives me 40 lines by 140 characters with the default set of panes on the right, left and bottom.
For Visual Studio and Eclipse, I could probably go back and change the font size to be closer to my Epsilon setting and get similar results (if I'm ever motivated enough).
One added restriction. I really don't like lo-o-o-ong lines. There is a reading phenomenon called "doubling" where, when lines are too long, you lose track of which line is the next one you need to go back to when you read to the end of the current line. This is less of a problem in code than in text, given the "poetic" (as opposed to "text") layout of code. I still, however, find it reduces readability for me, especially when I have to scroll a couple of screenfuls to the right horizonally and then jump all the way back to the left and locate the next line of the code.
Given all of the above, I'm going to put 60 lines vertically by 100 characters horizonally into the standards document. We'll see what my team members think of my numbers.
Finally, apologies for the forced alliteration of the title. I just finished reading a new translation of Sir Gawain and The Green Knight (by Simon Armitage), where there is heavy use of alliteration. If you like that sort of book, this one's a good read.
Note that this restriction is relaxed for methods that are case statements with many similar, small cases, or other simple and repetitive structures. Since these are more "data"-like than "code"-like, having to scroll up and down doesn't interrupt my flow of thought as much as with regular code.
I currently have a Dell flat-screen that I measure at 22" (559 mm) visible diagonal size (regardless of what the Dell sales literature says...). I run it at its default resolution (1680 horizonally by 1050 vertically). I have a few icons on my desktop on the left (heavy use) and right (lighter use), so that reduces my available screen size a bit. I also like to leave room at the bottom of the screen for the taskbar.
I bounce back and forth between three editors, my old standby Epsilon, the Microsoft Visual Studio Editor and Eclipse.
I run Epsilon at 8-point Courier New, which gives me approximately 60 lines vertically and 200 characters horizontally. I spend more time in this editor than the others, so I've spent more time getting it to settings that work for me.
I never changed the default settings for Visual Studio. When I configure it as I usually work (one column of panes on the right), I get about 45 lines vertically and 150 characters horizontally. Note that this is reduced during debugging, because more panes appear. Tools, Options, Environment, Fonts and Colors tells me that I'm using 10-point Courier New.
I also never changed with the font settings in Eclipse. Preferences, General, Appearance, Colors and Fonts tells me that I'm using 10-point Courier New. This gives me 40 lines by 140 characters with the default set of panes on the right, left and bottom.
For Visual Studio and Eclipse, I could probably go back and change the font size to be closer to my Epsilon setting and get similar results (if I'm ever motivated enough).
One added restriction. I really don't like lo-o-o-ong lines. There is a reading phenomenon called "doubling" where, when lines are too long, you lose track of which line is the next one you need to go back to when you read to the end of the current line. This is less of a problem in code than in text, given the "poetic" (as opposed to "text") layout of code. I still, however, find it reduces readability for me, especially when I have to scroll a couple of screenfuls to the right horizonally and then jump all the way back to the left and locate the next line of the code.
Given all of the above, I'm going to put 60 lines vertically by 100 characters horizonally into the standards document. We'll see what my team members think of my numbers.
Finally, apologies for the forced alliteration of the title. I just finished reading a new translation of Sir Gawain and The Green Knight (by Simon Armitage), where there is heavy use of alliteration. If you like that sort of book, this one's a good read.
Saturday, March 29, 2008
CSharp command parser example
I've added a CSharp example to the command lookup example code at http://code.google.com/p/dead-simple-command-lookups/. This, along with the C++ example, are as far as I plan to go. I (currently) don't use other langauges, and thus have no need to keep other versions readily available.
Ah, the truth comes out. I didn't really put this up for others to use (although they are certainly welcome to do so, given that the code is under the MIT license). I just wanted to have this code readily available when I needed to use it.
Ah, the truth comes out. I didn't really put this up for others to use (although they are certainly welcome to do so, given that the code is under the MIT license). I just wanted to have this code readily available when I needed to use it.
Wednesday, February 13, 2008
No Whining! (...at least not today...)
Rather than complain about something, today I want to contribute. I have been working on some very simple command lookup programs in various languages. I've finished most of them (one more to come - the C++ version). They are in Google Code at http://code.google.com/p/dead-simple-command-lookups/. Note that I've put the files into the download section as well as under Subversion for those that don't want to bother with getting a Subversion client running.
Wednesday, January 30, 2008
Cell Phones Are Still a Compromise
I have a cellphone but it's off most of the time. I've given out the number to very few people, and they know that I keep the phone off most of the time. Since I don't have call blocking enabled (that I know of!) anyone I call can grab my number. Since I don't, however, call that many people, I don't worry about who they are.
A number of months ago I interviewed at Google. I didn't get the job (sigh) but that's bits into the bucket. One of the pieces of information that came across in one of the emails (from their recruiter) was that they preferred that their interviewees NOT use cell phones during the phone screens.
This intrigued me. I'm not sure whether this is because cell phone networks in some countries aren't up to snuff or for some other reason(s). I do know from my own personal experience that about half the cell phone calls I make have dropouts or clarity problems, even in "civilized" places like the San Francisco Bay Area. Which actually is the primary reason I don't turn my cell phone on unless absolutely necessary.
A number of months ago I interviewed at Google. I didn't get the job (sigh) but that's bits into the bucket. One of the pieces of information that came across in one of the emails (from their recruiter) was that they preferred that their interviewees NOT use cell phones during the phone screens.
This intrigued me. I'm not sure whether this is because cell phone networks in some countries aren't up to snuff or for some other reason(s). I do know from my own personal experience that about half the cell phone calls I make have dropouts or clarity problems, even in "civilized" places like the San Francisco Bay Area. Which actually is the primary reason I don't turn my cell phone on unless absolutely necessary.
Thursday, January 24, 2008
JavaScript Strikes Again
In a recent job interview, I was asked how does one detect (in a JavaScript function) whether a parameter actually had a value passed to it. It's been a long time since I've done any JavaScript, so I answered that I assumed there was a way to test for "null". The interviewer said that I had the appropriate concept, but the actual language keyword to test against was "undefined". We then had a brief discussion about null versus undefined, but I wanted to find out more.
Google turned up this page which has some very concise and useful examples. I was not amused, however, to read that testing for null will return true regardless of whether the value is actually null or undefined. I would hope that testing for undefined doesn't return true for null, and I hope to have time to test this sometime in the future. This brought me back to the first time I realized that JavaScript didn't (in previous incarnations, anyway) syntax check code that was never executed. I'm used to that happening for shell script, but it brought me up short for a language that actually seemed to be used in many shipping products.
I guess one works with what one is given, but it doesn't make me any more confident in JavaScript as a robust language.
Google turned up this page which has some very concise and useful examples. I was not amused, however, to read that testing for null will return true regardless of whether the value is actually null or undefined. I would hope that testing for undefined doesn't return true for null, and I hope to have time to test this sometime in the future. This brought me back to the first time I realized that JavaScript didn't (in previous incarnations, anyway) syntax check code that was never executed. I'm used to that happening for shell script, but it brought me up short for a language that actually seemed to be used in many shipping products.
I guess one works with what one is given, but it doesn't make me any more confident in JavaScript as a robust language.
Thursday, January 17, 2008
Today's Formatting Hobgoblin
One of the little things that bothers me about some of the code I work with is the variation in handling of the "if" statement. In this code an "if" with a single statement in the "if" block (and no "else" block) will end up on one line:
if (condition) do_something_else();
I find this interrupts my reading of the code. I realize that putting brackets around the statement in the "if" block and putting the statement on its own line will add two lines to the code. I find, however, the consistency of formatting makes the code easier to read (for me, anyway).
This may be a foolish consistency or not. I looked back to my favorite coding standard for support. The Linux kernel coding style says "Don't put multiple statements on a single line unless you have something to hide." This doesn't mention brackets, but that follows from other standards.
At least I'm not the only voice crying in the wilderness...
if (condition) do_something_else();
I find this interrupts my reading of the code. I realize that putting brackets around the statement in the "if" block and putting the statement on its own line will add two lines to the code. I find, however, the consistency of formatting makes the code easier to read (for me, anyway).
This may be a foolish consistency or not. I looked back to my favorite coding standard for support. The Linux kernel coding style says "Don't put multiple statements on a single line unless you have something to hide." This doesn't mention brackets, but that follows from other standards.
At least I'm not the only voice crying in the wilderness...
Subscribe to:
Posts (Atom)