 |
|
 |
I won't speculate on what the "right" or "wrong" answer is here, but I do appreciate that you're willing to engage in speculation about naming conventions. There are some widespread practices in this area that probably would not hold up to scrutiny. I like the way you've engaged in such scrutiny, and done so from the developer's perspective. Identifiers are not just sources of information, they are things that we have to type repeatedly, search for, look for in Intellisense, and so on.
|
|
|
|
 |
|
 |
I google landed on this article looking for something else and the idea reminded me that I've often thought about how to better organize method verbs inside of a class, project, solution, company, enterprise and even ego allowing the development community. I read this article more as a forum post asking developers for feedback rather than an article guiding the reader in one direction or another. It probably could have been written better with a little more care but the idea is sound.
There are probably more mature threads on the topic. I did a quick google and didn't quite come up with anything I could link here. Maybe someone else could.
My thoughts on the topic are not english related or even intellisense related. Obviously, in the Microsoft Naming Conventions you do see some verb patterns emerge. Common method verbs include UpdateFoo, RefreshFoo, DoFoo (my favorite), PerformFoo, etc... All jokes aside about making "Do" a verb for a method at least when I'm searching for a method that is MS code I know to check certain verbs first, intellisense or otherwise, when looking to perform some action, whether it be a windows control, asp.net control, etc.
Now consider methods involving SQL. Should they start with InsertFoo, DeleteFoo, etc.? I say they should for the simple matter of clarity. I know when I'm browsing my own code if I see a method that begins with "Insert" I, at some point, wrote some code inside that method that inserts a record into a SQL table, more than likely. To me, it also reads well against a business object. (Contact.Insert() or Contact.Update()) for example. (Yes I'm well aware of nTier software development but sometimes working on a tiny projects doesn't warrant writing or even implementing a DAL so yes I do have some Contact.Insert() type code out there
The real issue is there are so many tasks being accomplished by each and every application that you can't possibly account for each inevitability of course. I would love to hear some decent discussion on the matter and possible links to other threads that address the topic.
One other major issue I have as a contract software developer is my "good sense" doesn't always come into play or isn't even allowed to come into play. Take, for instance, working with a new client that has a massive code base. They either have a defined coding standard including verb choices or those verb choices have evolved naturally over the course of the project or company or hopefully at least through the personalities/developers that have contributed to the project. Me trying to force feed my naming conventions into their project because "I'm right and they're wrong" isn't really debateable. It's just poor form. I have often thought about a way to better understand and visualize a project or solutions verb choices more clearly and quickly. To be honest I didn't spend enough time and it just isn't a high enough priority but lately one thing sparked up my thoughts on the idea again. The "word cloud" controls you see everywhere on the web. If the project/solution you're working with is at least, hopefully, following a "verb-first" naming convention, you could reflect all of the methods in said solution and produce a useful word cloud that illustrates that projects verb choices. Just a thought.
Anyway nothing in this article is ground-breaking or new but I will give it a 5 for selfish reasons. I want to bump it and get some good feedback from other developers much like the author, I belive.
|
|
|
|
 |
|
 |
Well ... to me, what proposed here is a good idea.
I understand the conservative point to don't force unrequested changes when deploying a module of a more complex software that already have its own conventions, but it is also true that if no-one ever try to push something, everything never changes.
I also have to consider that the most of the software, when talking to users, first ask to select a "subject" and then to require an action ("the right click after selection GUI concept). Neverless, the mother of all menu commands is "File/Save" and not "Save/File". So, if this is good for whatever user, why shouldn't be for programmers too?
Anyway, your idea of "word cloud" is great: just break identifiers by capitalization or by "_" and index them through their respective sub-words.
Whatever you are searching for (is it verb or subject or adjective or whatever complement) you'll find it.
But there is a risk: 80% of the cloud surface could be covered by a big "DO"
Do you know any IDE actually applying such concept?
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
 |
|
 |
No, I don't know of any IDE that supports a word cloud type of interface using reflection/method names, etc. Of course, I must admit I work solely from Visual Studio and don't have time for much else. I would love to check out Mono again and haven't for a few years now. So, as far as I know (humbly) it's still an original idea but feel free to run with it and send me a link to your completed VS Add-In by all means Maybe I'll actually contribute my first Code Project article...
I do agree if "nothing changes nothing changes". I do try to recommend naming conventions, standards and patterns at least in new development with projects that I work on. Of course, sometimes you get a hard nosed C++ guy in the dev lead chair that actually still wants some flavor of hungarian notation... What to do? A possible "strip hungarion" option in intellisense might be cool but it's so rare these days (thankfully) that it's probably not worth the effort.
As far as grouping methods one feature I do like is #region. What I would really like is a tool that gathers methods and properties in a MSDN approach defined by regions. By that I mean I would like to righ-click on a class in the Class View inside of Visual Studio and have a "Organize Regions" option. This would then reflect the class and place methods/properties in regions by access level. e.g.
#region "Private Fields"
#region "Protected Fields"
#region "Protected Properties"
#region "Public Properties"
#region "Private Methods"
#region "Constructors"
and so forth...
Since I figured out the key-combination to collapse/expand regions and other code groupings (CTRL+M+M by default) I can't live without this feature. The problem of course is classes are typically either not grouped in regions at all, or worse just properties, fields, constructors and methods scattered all over the place. Access level (public/private, etc.) is a very good starting point to find what you're looking for if you're a consumer of a class. For instance you can typically ignore most of the private fields, methods, properties (if any), etc. If I find a product that accomplishes that, possibly with some configuration options I'd purchase it in a heartbeat. I have looked and found nothing so if anyone knows something I don't...
I realize some of this comes from the point of a contract/independent software developer but I've worked with corporations as well. Not to mention, I'm working with large teams source code in the first place that almost always suffers from these types of code convention and organizational problems.
|
|
|
|
 |
|
 |
As mentioned in both some of the feedback as well as the article itself, there is wisdom in defining and sticking with a naming convention. Depending on the size of the team and the personalities involved, change or flexibility in the standards is acceptable. Especially the case of the small shop or individual, sudden reasoned change can be beneficial, whereas whimsical change can be simply change for the sake of change which produces nothing.
Regions have been mentioned as something desired by some, but I have heard of many, including myself, that loath them. Much of this is taste and I can accept those who have preferences that I do not have, just as it is acceptable if you like contemporary music while I like classical.
Personally rather than using regions, I make heavy use of partial classes and separate logical segments of a class into physically separate files. This allows particular segments to naturally appear in separate tabs and be instantly visible in the file tree. For example I might have Class.cs and Class.Xml.cs to separate XML serialization methods.
The bottom line is that software remains an art that includes a variety of styles. Arguments as to which is better, VB or C#, are frequently laced with personal preferences and prejudices, rather that reasoned assertions. An attempt was made in the article to make a reasoned assertion, but admittedly since it is now the technique used at DirectorWare, there is now a preference for it.
|
|
|
|
 |
|
 |
"Regions have been mentioned as something desired by some, but I have heard of many, including myself, that loath them. Much of this is taste and I can accept those who have preferences that I do not have, just as it is acceptable if you like contemporary music while I like classical."
This is certainly a preference of mine.
"Personally rather than using regions, I make heavy use of partial classes and separate logical segments of a class into physically separate files. This allows particular segments to naturally appear in separate tabs and be instantly visible in the file tree. For example I might have Class.cs and Class.Xml.cs to separate XML serialization methods."
I see no need for this, imho. Taking your example I would write a generic class (and have one for XML serialization e.g. (static class) XmlSerailizer.Serialize(string path), which also handles caching the XmlSerialization classes because of the reflection overhead due to loading a new type).
Anyway I digress, maybe it's not a great example on your part but I try to keep object specific code as truly unique to that object. Otherwise, the question becomes why not go generic, or an extension or some other language feature that's better fitted for such needs?
I typically only use partial classes with generated code which they are, of course, perfect for. I would consider breaking up a large class in a multi-developer environment that's still using an antiquated check-in/out source control software possibly. For personal development switching files is much more tedious than collapsing the regions or methods and finding the name or even resorting to the method drop down list.
Certainly personal taste enters into almost every factor of software development. That's why new tools must take into account the very wide variety of the reasonable although differing approaches that are available. VB vs. C# could be considered one of those decisions and often is in a multi-dev team, etc. ad nauseum.
|
|
|
|
 |
|
 |
DirectorWare wrote: "Personally rather than using regions, I make heavy use of partial classes and separate logical segments of a class into physically separate files. This allows particular segments to naturally appear in separate tabs and be instantly visible in the file tree. For example I might have Class.cs and Class.Xml.cs to separate XML serialization methods."
Dave Jellison wrote: "I see no need for this, imho. Taking your example I would write a generic class (and have one for XML serialization e.g. (static class) XmlSerailizer.Serialize(string path), which also handles caching the XmlSerialization classes because of the reflection overhead due to loading a new type).
The “Class.Xml.cs” example I think is actually a good one since we are working on an article that addresses using our freeware RestDirector product in XML serialization. Since it is a rather different approach than what Microsoft has in the .Net Framework, it does require some hand coding in exchange for a radical performance increase, partially due to no reflection requirement. Therefore, the XML serialization is class specific and placing it in separate file or region makes sense.
But we miss the point. A given class may have functionality to render some HTML or XAML (class.Html.cs), do data access to a SQL database (class.Sql.cs), read and write settings (class.Settings.cs), the list goes on. What you might group into regions, I group into files. To get to the part of the class I’m interested in I double click in the file tree, rather than collapse the regions and then expand the one I want. Like regions it also keeps related stuff together so I can have most or all of what I’m interested in on my screen at once.
A second plus is that ClassA may have some of the method groups and ClassB may have a different mix. Simply looking at the file tree gives me instant knowledge of what class has what.
We are back to taste. Just as I tell my kids and practice myself, I try a variety of foods, especially from a different culture or country. Some I like, some I don’t, but I have gained from the experience. I tried regions and partial classes and found one I like and one I don’t.
|
|
|
|
 |
|
 |
I don't understand people voting "1" for this article.
It's not a long and complex article introducing new concepts
It's not an article providing useful ready written code
It's not an article providing never heard suggestions.
Ok: but it pose a simple consideration that can be useful and can be discussed. One may agree or not, but t doesn't seem to me the case to say "shut up".
So I try to balance voting 4, and making the article available.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
 |
|
 |
There is a “club” mentality in most every field including software development. When you suggest something, new or not, that violates the “club rules” there is frequently a significant group that will either dismiss you or flame you. So be it.
Good engineering required a constant reexamination of the norm. Many practices, including verb first, date back to before IntelliSense. IntelliSense sorts alphabetically. I personally find the natural grouping of the alphabetic sort to find similar methods more important than being able to say the method name using proper English.
|
|
|
|
 |
|