Comments on: What’s in a Name? http://www.red-sweater.com/blog/127/whats-in-a-name Mac & Technology Writings by Daniel Jalkut Fri, 8 Aug 2008 01:21:36 +0000 http://wordpress.org/?v=2.6 By: Daniel Jalkut http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3951 Daniel Jalkut Fri, 05 May 2006 14:15:43 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3951 Yeah it seems the refactoring tools are really a missing bunch on Mac OS X. Perhaps this is a good business opportunity for somebody! Yeah it seems the refactoring tools are really a missing bunch on Mac OS X. Perhaps this is a good business opportunity for somebody!

]]> By: ebob http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3688 ebob Tue, 02 May 2006 17:02:49 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3688 I tend to get stuck on names only when a critical design is involved. That gives me loads of time to come up with a name for the class I'm designing on paper (or in Omni Graffle or whatever) before I wrote code. For less important classes I just pick a name that seems reasonable so I can get along. My stressing about names is reduced (and I do stress about it, too) because I have no problem with making massive changes to rename classes, methods and variables. The only time it becomes critical for me is when I have written code coworkers are interacting with often, and even then I'll rename, often when I refactor other unrelated items (renaming is a simple kind of refactoring, I hope) A good refactoring tool will make renaming even easier than global search. I don't know of any such tool for use within Xcode, nor for Objective C. There ought to be some free-standing tools for C++. I tend to get stuck on names only when a critical design is involved. That gives me loads of time to come up with a name for the class I’m designing on paper (or in Omni Graffle or whatever) before I wrote code. For less important classes I just pick a name that seems reasonable so I can get along. My stressing about names is reduced (and I do stress about it, too) because I have no problem with making massive changes to rename classes, methods and variables. The only time it becomes critical for me is when I have written code coworkers are interacting with often, and even then I’ll rename, often when I refactor other unrelated items (renaming is a simple kind of refactoring, I hope) A good refactoring tool will make renaming even easier than global search. I don’t know of any such tool for use within Xcode, nor for Objective C. There ought to be some free-standing tools for C++.

]]> By: Lee http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3488 Lee Sun, 30 Apr 2006 13:04:54 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3488 I wouldn't worry about commenting a class that you think the class name might be renamed in the future. I'd spend time to think about what you are going to name the class, but if you cannot get the perfect name, use the 2nd best and move on. Usually, even the names that you expect to be perfect might in the end be renamed as you learned more about the innards of your app. I like to expect that the names of all my entities are subject to change and that doing so is perfectly natural and "the right thing to do". I think what is most important is that you keep your design flexible to allow yourself the ability to change the names of classes, methods, variables, etc as it becomes appropriate. Having the right tools to do this (like subversion) as well as good refactoring tools definately helps. Is there a refactoring tool for Xcode? I wouldn’t worry about commenting a class that you think the class name might be renamed in the future. I’d spend time to think about what you are going to name the class, but if you cannot get the perfect name, use the 2nd best and move on. Usually, even the names that you expect to be perfect might in the end be renamed as you learned more about the innards of your app. I like to expect that the names of all my entities are subject to change and that doing so is perfectly natural and “the right thing to do”.

I think what is most important is that you keep your design flexible to allow yourself the ability to change the names of classes, methods, variables, etc as it becomes appropriate. Having the right tools to do this (like subversion) as well as good refactoring tools definately helps.

Is there a refactoring tool for Xcode?

]]> By: Daniel Jalkut http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3448 Daniel Jalkut Sun, 30 Apr 2006 05:27:14 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3448 Taybin: Yeah - to be honest as soon as I posted this entry I had second thoughts about the perhaps dramatic advice to name things super-strange as a marker. I still kind of like the pure honesty of it, but I agree that it's probably not very useful in a large group environment. I would probably do it in my own code but not in a shared repository. Your suggestion to just leave self-effacing comments nearby is probably a better choice. Andy: An interesting point - connecting the naming conundrum to googlability. It's true that what you identify is yet another christening problem we face as developers. NAMES! Arrrrr! Taybin: Yeah - to be honest as soon as I posted this entry I had second thoughts about the perhaps dramatic advice to name things super-strange as a marker. I still kind of like the pure honesty of it, but I agree that it’s probably not very useful in a large group environment. I would probably do it in my own code but not in a shared repository. Your suggestion to just leave self-effacing comments nearby is probably a better choice.

Andy: An interesting point - connecting the naming conundrum to googlability. It’s true that what you identify is yet another christening problem we face as developers. NAMES! Arrrrr!

]]> By: Andy Lee http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3446 Andy Lee Sun, 30 Apr 2006 04:30:42 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3446 I agonize over class, method, ivar, and application names all the time. To me this goes along with having, or at least working toward, a crisp idea of what I'm trying to accomplish and how I'm accomplishing it. Naming reflects how well my logic is factored and therefore how conveniently it can be subclassed. And it affects how clear and consistent the documentation will be. These issues are important to other programmers who will read my code (and I treat my future self as an "other programmer"). I want to be able to do global search-and-replace operations when I decide to rename something. Even without replace, global search can be useful. So I use naming conventions like two-letter prefixes and typographic conventions like leading underscores. Another kind of "search" issue is "googlability." Not only do I want people to be able to find my app via Google; I also want to be able to do vanity searches to see what people are *saying* about my app. I often wonder if I could have thought of a nicer name for AppKiDo, but in any case it is trivial to find with Google. I had an idea once for an app that I would have loved to call "BRANE," for "BRowse, ANnote, and Edit," but it turns out that word has a special meaning to physicists. (I never did write that app -- it's still on my mind, though.) Right now I'm working on a very small tool that I'm currently calling "Xcop," for "Xcode project-file," but it turns out that is not very googlable. I agonize over class, method, ivar, and application names all the time. To me this goes along with having, or at least working toward, a crisp idea of what I’m trying to accomplish and how I’m accomplishing it. Naming reflects how well my logic is factored and therefore how conveniently it can be subclassed. And it affects how clear and consistent the documentation will be. These issues are important to other programmers who will read my code (and I treat my future self as an “other programmer”).

I want to be able to do global search-and-replace operations when I decide to rename something. Even without replace, global search can be useful. So I use naming conventions like two-letter prefixes and typographic conventions like leading underscores.

Another kind of “search” issue is “googlability.” Not only do I want people to be able to find my app via Google; I also want to be able to do vanity searches to see what people are *saying* about my app. I often wonder if I could have thought of a nicer name for AppKiDo, but in any case it is trivial to find with Google. I had an idea once for an app that I would have loved to call “BRANE,” for “BRowse, ANnote, and Edit,” but it turns out that word has a special meaning to physicists. (I never did write that app — it’s still on my mind, though.) Right now I’m working on a very small tool that I’m currently calling “Xcop,” for “Xcode project-file,” but it turns out that is not very googlable.

]]> By: Taybin http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3442 Taybin Sun, 30 Apr 2006 04:10:10 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3442 Do *not* name your classes SuckyClassFOO. What happens to the other poor sap who has to look at your code? If you don't like the class leave a /* XXX refactor this class */ comment. Do *not* name your classes SuckyClassFOO. What happens to the other poor sap who has to look at your code? If you don’t like the class leave a /* XXX refactor this class */ comment.

]]> By: David Eddy http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3405 David Eddy Sat, 29 Apr 2006 22:34:54 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3405 Did Apple do anything about automating the naming/identification process? We've now got free SQL engines... yet programmers are still wrestling with having to make up "good names" at the point of creation. Did Apple do anything about automating the naming/identification process?

We’ve now got free SQL engines… yet programmers are still wrestling with having to make up “good names” at the point of creation.

]]> By: Charles http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3383 Charles Sat, 29 Apr 2006 17:57:55 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3383 Well, to be fair, the old conventions like naming iterators "I" come from the days of punched cards, when longer variable names might cause single lines of code to exceed the length of a punched card, and more typing (actually punching) meant more likelihood of errors. Just be glad, very glad, that you didn't study programming back in the 1970s. Or even worse, in the 1960s, <a href="http://ceicher.homeunix.com/archives/2006/04/computing_with.html" rel="nofollow">here is an amazing example</a> of a 40 column Hollerith Card that you filled in with a #2 pencil. I actually used these cards to write FORTRAN programs. Well, to be fair, the old conventions like naming iterators “I” come from the days of punched cards, when longer variable names might cause single lines of code to exceed the length of a punched card, and more typing (actually punching) meant more likelihood of errors. Just be glad, very glad, that you didn’t study programming back in the 1970s. Or even worse, in the 1960s, here is an amazing example of a 40 column Hollerith Card that you filled in with a #2 pencil. I actually used these cards to write FORTRAN programs.

]]> By: Daniel Jalkut http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3357 Daniel Jalkut Sat, 29 Apr 2006 14:23:29 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3357 Charles: I did have some picky CS professors, but most of my education happened at Apple, where they thankfully subscribed to some pretty good naming habits. I would have to agree with your professor that single characters are not great for variable names. In fact, I usually avoid even the common shorthand of naming for-loop iterators "i". If you decide to search/replace on names like that it's a nightmare. Therefore, my for-loops usually involve the clumsy "iterator" variable. Scott: Good point and I think it supports my "if you fail, forge ahead" idea. But I do think at least a little bit of time thinking about what the ideal name would be can help prevent a lot of refactoring later. Arto: The tools problem is a great point. I can totally relate to the CVS issue, and I think my file-naming phobia stems from spending so many years using that crappy tool :) Since I've switched to subversion I find myself actively reminding myself that it will be no big deal to even rename a file or move an entire directory. Definitely helps with flow. Charles: I did have some picky CS professors, but most of my education happened at Apple, where they thankfully subscribed to some pretty good naming habits. I would have to agree with your professor that single characters are not great for variable names. In fact, I usually avoid even the common shorthand of naming for-loop iterators “i”. If you decide to search/replace on names like that it’s a nightmare. Therefore, my for-loops usually involve the clumsy “iterator” variable.

Scott: Good point and I think it supports my “if you fail, forge ahead” idea. But I do think at least a little bit of time thinking about what the ideal name would be can help prevent a lot of refactoring later.

Arto: The tools problem is a great point. I can totally relate to the CVS issue, and I think my file-naming phobia stems from spending so many years using that crappy tool :) Since I’ve switched to subversion I find myself actively reminding myself that it will be no big deal to even rename a file or move an entire directory. Definitely helps with flow.

]]> By: Arto Bendiken http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3342 Arto Bendiken Sat, 29 Apr 2006 11:14:49 +0000 http://www.red-sweater.com/blog/127/whats-in-a-name#comment-3342 I think the difficulty of naming things depends a lot on the tools you choose to, or have to, use. For instance, I worry prematurely about naming issues only when I work on client projects using either a) CVS for version control, and/or b) static, compiled languages. With projects managed through CVS, or with legacy code bases having other similarly limiting constraints, changing file names and refactoring & reorganizing the code becomes enough of a headache that it pays to get it right (or mostly right) the first time around, whenever possible. This thankfully ceases to be an issue with modern tools, like Subversion or Darcs, that are able to move files and directories around in the repository with their full revision history preserved. Again, with static languages, the cost of changing one's mind often becomes high enough that a certain non-trivial amount of premeditation and planning may be warranted. That's why I much prefer to work, when I can, in dynamic languages (such as Ruby and Scheme), where code can be naturally written in a bottom-up fashion, and a mere prototype can evolve, through lots and lots of low-cost refactoring iterations, into the actual first version of the program. It's liberating enough that I've learned to never worry about trivialities (such as naming), knowing I can change my mind at any time. Now, as for naming a product or a company, that's a showstopper indeed - speaking as someone who has spent way too much time checking domain availability and huddled up with Latin/Greek/Finnish/etc dictionary ;-) I think the difficulty of naming things depends a lot on the tools you choose to, or have to, use. For instance, I worry prematurely about naming issues only when I work on client projects using either a) CVS for version control, and/or b) static, compiled languages.

With projects managed through CVS, or with legacy code bases having other similarly limiting constraints, changing file names and refactoring & reorganizing the code becomes enough of a headache that it pays to get it right (or mostly right) the first time around, whenever possible. This thankfully ceases to be an issue with modern tools, like Subversion or Darcs, that are able to move files and directories around in the repository with their full revision history preserved.

Again, with static languages, the cost of changing one’s mind often becomes high enough that a certain non-trivial amount of premeditation and planning may be warranted. That’s why I much prefer to work, when I can, in dynamic languages (such as Ruby and Scheme), where code can be naturally written in a bottom-up fashion, and a mere prototype can evolve, through lots and lots of low-cost refactoring iterations, into the actual first version of the program. It’s liberating enough that I’ve learned to never worry about trivialities (such as naming), knowing I can change my mind at any time.

Now, as for naming a product or a company, that’s a showstopper indeed - speaking as someone who has spent way too much time checking domain availability and huddled up with Latin/Greek/Finnish/etc dictionary ;-)

]]>