I dont have a problem with coding standards. I have a problem with following something so strictly, even when it makes no sense at all - such as this class name.
Welcome to stack overflow! Censorship here is just as bad, if not worse, than Wikipedia. As much as I despise this, it probably does make it a better resource. Still, I wish they would MOVE these to meta exchange, rather than deleting content outright.
Wow! Could you elaborate by chance? I mean this genuinely, this is my first ever dead link for StackExchange content. The others in this comment thread act as if this is the norm, which is disheartening. Is this a recent phenomenon or something that I've just been luck/naive enough to miss this whole time?
There isn't much to elaborate on. Anything that doesn't fit completely within their strict no-fun-allowed guidelines gets removed. This leads to two things:
1. Any result on google from StackOverflow is guaranteed to be of the highest quality.
Sounds like a win win. There are hundreds of places for humor on the Internet. I'm pretty happy SO sticks with business. Humor would be distracting and irritating.
Why not Humor Overflow, where people can discuss what is funny and why, or why something isn't funny. Maybe why something is no longer funny -- or is funny in one language or culture, but not another.
Perhaps it is just the front-end issues I use SO for, but generally the top Google results aren't the most helpful for me; they're just the oldest and had, at one time, the most traction. Given the rate at which things change or other methods fare better, I've started sorting my results by date instead of relevancy and hoping Random Dude's Blog has the right answer. Sometimes you'll get lucky and someone will have posted an updated response, but it's still sitting at the bottom of the page with 0 votes, and my account doesn't have the reputation (due in part to not wanting my posts removed) to upvote them. Quite a cycle.
It's not a dead link per se. Users with high enough reputation can still see it. But for the web at large, it is dead, indeed.
Many questions from the early days of SO were closed because they were too humourous or didn't fit the “needs an objectively correct answer” – this included a lot of such “poll” questions like “What is your favourite ...?”.
I doubt that it makes SO a better resource. I've seen the CV patrols in action. These are teenage kids hanging out in chatrooms, gaining enough rep to close-vote (which is easier than you think) and then throwing themselves like hungry mobs on interesting questions to shut them down.
The moderation system on stackoverflow is broken because an unskilled user can gain high reputation by getting upvotes from other unskilled users (I've seen a lot of wrong answers getting up-votes). This means that over time the average level of skill in the people moderating the site drops and you end up with a lower quality of moderation.
Just an anecdote that probably says more about me than about the internet:
Recently I had work on a shell script that used "sed" to make changes in config files. At some point a change only had to happen once a line with a certain string had been seen, so I googled for this situation.
Multiple StackOverflow answers were at the the top of the results as well a several other sites all of them containing incomprehesible examples of line noise. Half the time, the comments on the pages with the aformentioned examples also indicated the solutions didn't work.
So I did a "man sed" looking for examples but it was a pretty short man page which told me to peruse "info sed". Not expecting much I fired up info (which I generally try to avoid: just put your docs in the man page) and to my surprise there was very good and clear documentation on sed which got me to fix my initial problem in 5 minutes in a clear way (well, it did need a comment in the code).
The next time I need to know anything about sed I will check the manual first.
As good or bad as the Java language may be, I think plenty of people are turned off by the Java culture that encourages this to happen. This is a little bit of an understatement since Sun setting the defacto coding standard gives a very strong message to followers.
The rest of the world might simply say blah.bah.frame.paint and be done with it.
Interesting. It's long, but it's also pretty clear on what it does, and doesn't have any repeated words.
Reading this, I would guess that it's a notification of when the user starts editing a column, and indeed that's what it does. "Informs the System.Windows.Forms.DataGrid that the user has begun editing the column." is the official description in the API.
IMHO it's not close at all. First, the namespace shouldn't be counted, leading to a huge difference in sheer length. Second, the words in the BCL name, more or less, form a comprehensible noun phrase. Third and anyway, this is the longest public class in the BCL, whereas the article describes an internal class; a much higher bar should be held for public names.
Seems like automatically generated class name. You shouldn't ever see that as a Java developer unless you work for Sun, since this is internal package. The name, though long, seems pretty consistent with the rest of the names in the package [1].
If you look at it once more I guess that it is used as a Painter for MaximizeButton located in InternalFrameTitlePane of InternalFrameTitlePane of InternalFrame.
Given the name, it sounds like this piece of code is drawing window decorations despite not being part of a window manager. (Though it's unclear, it might be doing window decorations in an MDI-like context.) This object probably shouldn't even exist in the first place.
Using private internal classes or something. Even with namespaces it'd look okay, so you'd go InternalFrame.TitlePane.MaximizeButton.Painter() or something (I've forgotten Java tbh) and that actually looks okay to most programmers IMO.
I'm guessing this shouldn't even be exposed to anything outside of an InternalFrame anyway.
Also, in the package com.sun.java.swing.plaf.nimbus, there lies the infamous class InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState (http://codenav.org/code.html?project=/jdk/1.6.0_22&path=...). Quite a precise name for a class that has only 36 lines.
Talking about design patterns, the folks that develop the Spring framework apparently tried to put as many of them together as they could: there is a class named AbstractSingletonProxyFactoryBean (http://static.springsource.org/spring/docs/2.5.x/api/org/spr...) in the aop package. And, the class description is no less than "Convenient proxy factory bean superclass for proxy factory beans that create only singletons".
No. It's a convenient superclass that allows beans that are themselves factories to create proxy objects. It just so happens that these proxies are singletons.
Basically it's been deprecated, but its used for AOP interceptors. It gets a lot of flack, but there was a reasonable reason for the Spring developers to have created this class.
Oh, and the original documentation is pretty comical. But the latest documentation makes it very clear what it does:
E.g. TraversableResolverSpecifiedInValidationXmlNoDefaultConstructorGwtTest , DeleteContentTypeXmlDocumentResponseDeleteContentTypeXmlDocumentResult , and so on.
I know these test names might seem insane. And I personally hate the Java FactoryFactory culture of over-engineering. But, the super long test class names are actually pretty nice. I've personally never gone quite that crazy with the names, but I have definitely used more than 80 characters total for the class and particular function named for a test.
These super long names not part of any client interface, no one is ever going to have to type that monstrosity except for the guy writing the test. But when you see the failing test output that prints the test name, you already know what is failing.
You can have a small class name and a (comparatively) long comment, or just a long class name. Considering there is now no need for a comment and the test name is actually useful for debugging failed tests easily (you don't need to "dereference" the short test failure name to get the surrounding comment), this style is actually a win.
Some test tools generate test descriptions from names - so TraversableResolverSpecifiedInValidationXmlNoDefaultConstructorGwtTest looks in test report as "Traversable resolver specified in validation xml no default constructor gwt". Which may actually lead to more readable reports and nobody uses test classes to instantiate them except for automatic tools anyway. So these class names are not as insane as it seems. For non-test classes such name would be completely insane of course - or routine in case of Java :)
It's said that Lisp programmers often work by first building a domain-specific language for solving their problem, then solving the problem in that new language.
Some object-oriented programmers do something similar, where their programs are expressed in a domain-specific language written as an object relationship graph. Only they skip the part where that language is supposed to make it easier to solve the problem.
It has all the hallmarks of production code I've seen in this style: it's about 20 times more than the necessary amount of code, it's subtly buggy, and it needs explanation because what it does is completely non-obvious.
It is arguably slightly easier to extend than the obvious solution, but at a great cost, and in a silly one-off program at that.
The worst part? This doesn't scream parody in some circles. This is just how things are done, as if anything less involved is fundamentally broken.
> It's said that Lisp programmers often work by first building a domain-specific language for solving their problem, then solving the problem in that new language.
This is precisely how good Smalltalkers operated. It was very doable, because even constructs like conditional logic and "looping" (really iterators) were just ordinary calls. For example, if you wanted to implement "fuzzy logic" in Smalltalk it would just take a mere minutes to implement some methods like:
ifTrue:ifFalse:ifMaybe:
Then define a Maybe class and use it as the Maybe value and park some methods like that on it. Then this would let you write code like:
I'm a bit worried at how easily I was able to follow that code. And that my initial reaction was to think "Iterator.next() should throw a NoSuchElementException if there is no next element!"
I just did a quick analysis of a system with a large number of globally exposed names written in C.
About 1000 functions in all (so that's just the globals), of those a hundred have names > 30 characters. There are some real 'gems' in there, consistency - even if self enforced - has a price. The record holder weighs in at 53 characters, it (fortunately) drops off quickly after that.
There are only 2 things hard in programming, cache invalidation, naming things and off by one errors.
Personally I think this name is bad because in spite of the enormous length it still doesn't tell me what it actually does. It just uses a lot of characters to indicate its spot in a hierarchy.
Names like these are what gave rise to jokes like 'Q: What is the spelling of bureaucracy? A: J-a-v-a'. Which of course does a dis-service to java the language and the community behind it.
I can see why they're funny, but you have to realize that when you get out of the trivial program length domain into projects that are 100's of thousands of lines that this problem will sooner or later rear its ugly head. And I have not yet seen any really good solutions.
The things that can help you to extend your runway a bit in this respect are:
- be consistent
- reduce scope wherever possible
- pick short names for primary objects
But even with those rules you'll have a 53 letter name in there somewhere... I'd be very wary of casting stones in situations like these without knowing exactly how the person that picked it originally made their choice. Chances are there were a whole pile of external factors dictating this monstrosity and the guy or girl (or the code generator!) that did it never was happy about it either. Laughing at others that have tackled some problem is easy. Coming up with real solutions and doing a better job of it is a lot harder.
Your last 2 sentences exactly describe where most programmers fall into these days.
1) Most of us never tackle specific problem domains that are very rare
2) Most of us never come up with real world solutions
Most of us these days work on CRUD web-app with only a few who actually go deep into specific problem domains.
Sometimes the problem domains is just that hard. I know there are optimistic developers out there that keep saying "I can simplify this particular problem domains" but here we are in 2012 still writing CRUD web-app.
No. That is just wrong. There is no problem domain that requires the use of very long strings to refer to individual pieces of it. All systems, either statically or dynamically, can be decomposed into smaller pieces who's names are short because they are meaningful within the context of another name.
Or, to put it another way, you get names like this when you statically code a data-structure that should be dynamic.
What would you call a function that is globally visible (as in: can be called from anywhere) that serializes a construct called a router_msg_header into xml, and that returns the generated xml as a utf8 string?
Assuming there's no relation between the xml header and any other headers you might have, the atomic core of the noun phrase is "XML header" so I maybe utf8 should be a (optional?) parameter.
It depends on how you organize your utility classes. For example, if your project has a lot of serializers, then you might have a package that contains them. Or you might create a bunch of static methods on a single "SerializerUtils" class.
The other thing is that I prefer symmetry. I would probably write the function to take and return the same thing.
Finally, I might strongly consider writing a generic method that, using reflection, traverses arbitrary data structures and constructs an XML DOM. The caller can do what it needs, e.g. serialize into a string.
If, for some reason, your system requires a specific transformation from a custom data structure into a string, then it belongs in the custom data structure class - possibly a toString method, or something more specific.
So, we are in agreement I think. The example I picked wasn't from java but C (but that's almost irrelevant), so your:
RouterMessageHeader.toXMLString();
Ended up as
router_message_header_to_xml_string();
So 35 characters in all. Not quite terrible but also not very elegant. At least it says what it does :)
I still can't help the feeling that the data structure leaked into the naming of the function and I see no way to solve that, I can't even imagine how one would go about that and still have a function with global scope (in itself something that you'd try to avoid wherever you could, but in this case we can't for various good reasons).
I've looked at making this a generic system but that increases the overall complexity of the bookkeeping (creation, destruction, modification) around the objects to such an extent that it probably isn't worth it (though I can see some other advantages of this approach, such as easier debugging).
It would probably be instructive to consider what it would mean if you extend this out further. If we have a function that also ships it out on a socket, are we going to get
send_router_message_header_as_xml_string(...)?
If it also does error handling of some sort, are we going to embed that in the name?
My point is still ultimately the same as others here, but I'm trying to demonstrate it from the other direction. It isn't that the long function name is OK, it is that it is poorly decomposed into tasks. But digging another "why" back, the root cause for that is what you say later, that it "increases the overall complexity of the bookkeeping" etc., and the reason for that is that C isn't really that good a language for abstraction. After 40 years of experience with it we've managed to create some best practices that carry it far further than anyone could have imagined at the beginning, but when it gets down to it, when you have a language that doesn't abstract very well, you do eventually end up paying the price in functions like that. It probably is the right answer in C, no sarcasm, but that's not the same thing as saying it's the right answer in a more general sense.
(And to be more concrete, C has poor facilities for composing abstractions together without complication and loss. On a feature-by-feature basis you can make it do pretty much anything you want, Turing Complete etc etc, which makes it hard to see in blog-post-sized examples, but they don't wire together very well.)
What surprises me more is that given that it is 40 years old how well it holds up. Sure there are other languages that deal with namespaces better. But none of them is without warts and the trade-offs involved make C in spite of its age a pretty good contender for systems level stuff.
To be clear, I agree entirely. It is a credit that it has lasted this long. But I do think that we are well into a time where C should no longer be your default answer, but rather something you get backed into because there is no other valid choice. (Which still certainly happens.)
> Are there any 53-character function names in the multi-million line Linux kernel?
The linux kernel is actually only about 100 K lines. And its naming conventions are not what I'd call an example of elegance either, to put it very mildly (many of the names are quite cryptic and require extensive study of the code around it to understand what a function does). If low symbol length would be an indicator of code quality then we'd all be using fXXXX where X is a digit of your choice.
The longest symbol in the kernel proper that I can quickly locate is 36 characters:
timer_stats_hrtimer_clear_start_info
It uses roughly the same convention that we use in our projects (a quite common one in large C projects): a module prefix
(if possible the same as the filename) an action and a bit that specifies further details.
Even with that simple convention it can add up quickly.
And if you start linking against 3rd party libraries you're going to be looking at name clashes sooner or later, even if you're careful. Whoever at mysql decided to expose 'list_free', 'list_add', 'list_delete' and so on with global scope wasn't having their most lucid day. I wished I was kidding.
That bit is the kernel. File systems, drivers and so on are best though of as plug-ins to the kernel. Architecture dependent code would probably normally expose only one set of symbols rather than all of the code, probably should have included memory management.
Likely if you include all that code you'll turn up a few more longish names, but the net effect is pretty much the same: really long names are rare when you've laid things out properly but 30 characters and up are certainly no exception.
There isn't in the kernel itself but there is perl code in the build process. If you want to build the linux kernel without dependencies on interpreters then you're in for a rough time.
I figured; I was just being funny. Although actually the thought of embedding an interpreter of some kind in the kernel is very interesting. It would have to be an unusual interpreter, that's for sure, as it would have to operate without a kernel. I'm not sure if that even means anything though, as you'd probably end up implementing kernel-like behavior in your interpreter.
The example is not perfect, the function is not exactly globally visible, but I could argue that instanciation of the class is available globally. Or you could get by, by making it static. Also, it's true that I'm adding more characters than any other function name, but no single word I wrote has more than 13 character keeping it easy to read. Every subsequent call to this function will be nothing more than `RMG_Serialize().utf8()`.
Imho, if you feel you're forced to give this kind of name to your variables, there's something wrong either with the design or with the specs.
The choice of programming language counts as well. I mentioned static typing as the obvious example, but isn't a language nothing more than a framework to name your variables?
But I agree with you that maintaining your names short is difficult. I think this has less to do with technical limitations and more to do with project management issues. Generally, I think that a team that understands the value of refactoring (and manage to afford it) will always be better at avoiding this crippling problem.
> Q: What is the spelling of bureaucracy? A: J-a-v-a
(Excuse me if I've mentioned this before.) So, I met the guy who did the first implementation of Merge Sort which he wrote in assembly language on paper tape. One of his comments on C++ after noting how cluttered it could look: "So, is this today's equivalent of COBOL?"
> when you get out of the trivial program length domain into projects that are 100's of thousands of lines that this problem will sooner or later rear its ugly head
Global namespaces are evil. We have non-global namespaces, but programmers keep on acting like there's only one global namespace. In reality, in large projects, everything should be considered relative to intersecting areas of concern, and code should always explicitly reference the libraries being used locally. Python could be used this way, but I suspect most programmers act as if imports are just a way of getting what they want into their most convenient namespace, which effectively becomes the global one.
A module namespace in Python does not suffer from the same problems that global namespaces in other languages do, because what goes in there is under the control of the module writer, barring strange monkey-patching approaches.
That's not what I'm getting at, at all. The Python module/namespace mechanism is just fine. I'm saying that the developer community doesn't use it in a way guaranteed to keep million line codebases as neat as possible.
The embedded error is, of course, in itself off-by-one, but the actual cause could be cache invalidation -- the list was extended from two things to three without updating the length counter.
Exactly what I suspected as well. Just had that experience with this Go code-generator generating wrapper packages based on XSD files, here's a fine example: the "TxsdModesUnionTxsdModesUnionListTxsdModesUnionTxsdModesUnionListUnion" ( http://github.com/metaleap/go-xsd/blob/master/pkg/www.w3.org... )
Alternative would have been hundreds of "AnonN" identifiers with N going well into the hundreds...
I've only touched Java a bit, but AFAIK it has quite strict package hierarchy system that allows naming and grouping things nicely.
Why then people keep creating long class names in the first place? I get it that this particular example might be a generated name, but still, why not just create package hierarchy that represents the code properly?
Also wouldn't using package hierarchies automatically lead to a bit better design (more modular, more understandable)?
I primarily do java work (consulting) for enterprise. I've always seen it as a combination of convention and time.
There are java applications that have been around for decades. I've worked in codebases that are over twenty years old. Some of these systems are responsible for billions of dollars and have been heavily tested (the others are responsible for billions of dollars and have been barely tested).
Say you are a consultant, and you're working on a shipping application that has been around since the late 90's and is responsible for moving goods where the sum total of all items in transport over a year is larger than the GDP of Taiwan.
In that application there is a Warehouse interface. Simple thing, basically it has a receive() and distribute() method that moves product from one location to another (warehouse.receive(truck) or warehouse.distribute(200,truck)).
Around 2000 someone needed to create an edge case because specific warehouses are only available during specific times of the year. Like black Friday to Christmas. Usually it is too much overhead to keep all these warehouses running so they are only open 1/2 the year (this doesn't happen, but work with me). So someone created class TimedWarehouse that will do this calculation (on date X no longer receive).
Now it is 2012 and you are just a contractor. The big problem with the TimedWarehouse is at the end of the year you MUST VACATE ALL GOODS (because the warehouse is going to shut down). For the last couple of years product has been lingering in these warehouses keeping them open longer (costing more money).
The best way to handle this is perhaps a batch process job that sends emergency shipments as it gets closer to the end of the year. So something that cleans the timed warehouses out. Now you're just a consultant, you can't rework the entire framework but you must keep with convention... what to do
TimedWarehouseProcessor (nice... but doesn't indicate that it is only used towards the end of the year)
TimedWarehouseYearlyCleanout (makes more sense, but is terribly specific, what about warehouses that are open twice a year)
TimedWarehouseCleanoutManagementUtility (Bingo! More generic sounding, and it is a 'utility')
Imagine the poor sap who might need to extend that class. The process repeats over time. More contractors following the rules of convention, larger and larger class names.
You are right. That one looks like generated class name and it's internal. Just the very nice Javadoc generator exposes all names in the Javadoc and it becomes cannon fodder for language hipsters.
You can find quite a few of these, and every time I see them linked I shake my head in confusion.
I don't understand what I'm supposed to take away from this. That there exists in the world badly named Java classes? And? Is the implication here that because you found an example of a clumsily named Java class the entire language is an usuable write-off? Or that it's somehow indicative of all Java applications?
I know Java isn't cool, but I don't see what is achieved by staring, pointing and giggling because you found an example of its use that is ungainly.
This is not a code smell, but something larger, and much worse. Java is fundamentally an imperative language, and these names are evidence of the disconnect between that nature and what people think Java is.
One can argue that this is the result of ignorance, that "good" Java programmers will avoid this trap. And yet, for all it's restrictions, it doesn't give much refactoring guidance. The proliferation of patterns (both for creation and relation) in Java is a weakness, not a strength, and the result is monstrosities like this. Training, experience and convention avoids these traps, but why do we create new languages if not to reduce the amount of training, experience and convention that a programmer needs to learn in order to be productive with an environment?
I don't see how this name is a problem beyond giving cannon fodder for language hipsters to rant about Java.
How many programmers have been affected by this internal class? How many programmers have used it and complain about it?
Java allows long identifier names and gives people the freedom to name however they like. Why is that a bad thing? You want syntax rules in the language to force short identifier names? We had those long while back and it's a really bad idea.
And BTW what is so wrong about imperative? It's simple to learn and simple to follow. It has solved many problems, given whatever the real world constraints. Just because functional is the in-thing now doesn't mean imperative is totally bad.
Nothing! The problems occur when people think that it's not.
And I really disagree with your hipster comment. You can indeed accomplish any task with Java, but that is damning with faint praise. The question is whether or not the environment gives the programmer adequate refactoring pressure to guide his decisions. Java provides almost no such pressure, resulting in a mess.
Many problems have been solved in Java despite of this, not because of it.
> Nothing! The problems occur when people think that it's not.
I don't really understand what you are trying to get at. Is it wrong or it isn't?
The hipster comment is spotted on. This post is evident of that attitude. The OP has to dig up an internal class whose name is probably generated to bash Java. And your original comment basically went further and claimed this long class name is the evident of what is so wrong with Java in general.
If there's no pressing pressure to refactor, then it has work well for its purpose. You want to limit class name to 8 characters to force programmers to pick shorter name? It's an internal class, for god sake. What's the impact on 99.99% of the programmer out there?
Development is a process of compromise and trade-off. Developers don't have infinite time and infinite budget to code. They have to pick their battle and do the more important things.
1. You seem to know what most Java programmers think. What do Java programmers think of Java as if not imperative? And what is the thing that they assume Java to be leads to problems? Again what specific problem is the long class name causing?
2. Thank you for correcting my grammar. BTW the period goes inside the quotation marks as in "spot on."
3. While not often used, generated source code are useful as design calls for it. Not everything revolves around static and dynamic.
2. Both styles are valid and used (just be consistent about it in a single body of text). Arguably the period after the quotation marks more closely matches the actual sentence structure.
When I saw the title I thought, _that has to be java_. If it had included a "Factory" or "Manager" in there somewhere I would not have needed to look at the link to verify.
Some idiot is probably using booleans in some magic "arithmetic". A collegue once told me returning 1 for truth was handy because he could sum the results after a map, and compare the sum to the count of input elements to see if all succeeded. This only slightly more "handy" than returning TRUE and ANDing the result because you can say "X/N succeeded" (leaving the user to wonder which N-X failed is fine, I guess.)
I think Javascript also suffers from something like this: functions inside functions inside functions inside functions. If Java is the king (queen?) of horrible naming conventions, Javascript is the prince(ss) of horrible code structure. It might be why both are named Java...
var foo = function(foo, bar){
var bar = function ( function (x) {
this.something = function (z) {
return function (y){}}}}};
//or something like that. Only a fool would
think the code above is real or even correct.
155 comments
[ 5.5 ms ] story [ 197 ms ] threadBut seriously, this just highlights one of the downsides of following "coding standards" religiously.
Vogon poetry, to be specific.
1. Any result on google from StackOverflow is guaranteed to be of the highest quality.
2. I am never ever posting there.
Many questions from the early days of SO were closed because they were too humourous or didn't fit the “needs an objectively correct answer” – this included a lot of such “poll” questions like “What is your favourite ...?”.
The moderation system on stackoverflow is broken because an unskilled user can gain high reputation by getting upvotes from other unskilled users (I've seen a lot of wrong answers getting up-votes). This means that over time the average level of skill in the people moderating the site drops and you end up with a lower quality of moderation.
Recently I had work on a shell script that used "sed" to make changes in config files. At some point a change only had to happen once a line with a certain string had been seen, so I googled for this situation.
Multiple StackOverflow answers were at the the top of the results as well a several other sites all of them containing incomprehesible examples of line noise. Half the time, the comments on the pages with the aformentioned examples also indicated the solutions didn't work.
So I did a "man sed" looking for examples but it was a pretty short man page which told me to peruse "info sed". Not expecting much I fired up info (which I generally try to avoid: just put your docs in the man page) and to my surprise there was very good and clear documentation on sed which got me to fix my initial problem in 5 minutes in a clear way (well, it did need a comment in the code).
The next time I need to know anything about sed I will check the manual first.
I continuously bump into valid (if not about specific lines of code) programming questions closed by some CasperOne grognard.
http://webcache.googleusercontent.com/search?hl=en&safe=...
http://stackoverflow.com/a/891589
JDK has a superb auto document building tool to extract all the classes in JavaDoc and letting people to find internal classes easier.
The rest of the world might simply say blah.bah.frame.paint and be done with it.
[1]http://weblogs.asp.net/rchartier/archive/2004/02/05/68350.as...
Interesting. It's long, but it's also pretty clear on what it does, and doesn't have any repeated words.
Reading this, I would guess that it's a notification of when the user starts editing a column, and indeed that's what it does. "Informs the System.Windows.Forms.DataGrid that the user has begun editing the column." is the official description in the API.
Anyways, we are shaming Java here because of one obviously automatically generated internal class.
If you look at it once more I guess that it is used as a Painter for MaximizeButton located in InternalFrameTitlePane of InternalFrameTitlePane of InternalFrame.
How would you name such thing?
[1] http://javadoc.bugaco.com/com/sun/java/swing/plaf/nimbus/pac...
I'm guessing this shouldn't even be exposed to anything outside of an InternalFrame anyway.
Talking about design patterns, the folks that develop the Spring framework apparently tried to put as many of them together as they could: there is a class named AbstractSingletonProxyFactoryBean (http://static.springsource.org/spring/docs/2.5.x/api/org/spr...) in the aop package. And, the class description is no less than "Convenient proxy factory bean superclass for proxy factory beans that create only singletons".
Take that, GoF.
Basically it's been deprecated, but its used for AOP interceptors. It gets a lot of flack, but there was a reasonable reason for the Spring developers to have created this class.
Oh, and the original documentation is pretty comical. But the latest documentation makes it very clear what it does:
http://static.springsource.org/spring/docs/current/javadoc-a...
http://code.google.com/codesearch#search/&q=%5Cw%7B60,%7...
E.g. TraversableResolverSpecifiedInValidationXmlNoDefaultConstructorGwtTest , DeleteContentTypeXmlDocumentResponseDeleteContentTypeXmlDocumentResult , and so on.
These super long names not part of any client interface, no one is ever going to have to type that monstrosity except for the guy writing the test. But when you see the failing test output that prints the test name, you already know what is failing.
You can have a small class name and a (comparatively) long comment, or just a long class name. Considering there is now no need for a comment and the test name is actually useful for debugging failed tests easily (you don't need to "dereference" the short test failure name to get the surrounding comment), this style is actually a win.
Some object-oriented programmers do something similar, where their programs are expressed in a domain-specific language written as an object relationship graph. Only they skip the part where that language is supposed to make it easier to solve the problem.
What do I mean? Here's my (somewhat ancient) attempt at parody: http://pastebin.com/TyNrvRmB
It has all the hallmarks of production code I've seen in this style: it's about 20 times more than the necessary amount of code, it's subtly buggy, and it needs explanation because what it does is completely non-obvious.
It is arguably slightly easier to extend than the obvious solution, but at a great cost, and in a silly one-off program at that.
The worst part? This doesn't scream parody in some circles. This is just how things are done, as if anything less involved is fundamentally broken.
This is precisely how good Smalltalkers operated. It was very doable, because even constructs like conditional logic and "looping" (really iterators) were just ordinary calls. For example, if you wanted to implement "fuzzy logic" in Smalltalk it would just take a mere minutes to implement some methods like:
Then define a Maybe class and use it as the Maybe value and park some methods like that on it. Then this would let you write code like:About 1000 functions in all (so that's just the globals), of those a hundred have names > 30 characters. There are some real 'gems' in there, consistency - even if self enforced - has a price. The record holder weighs in at 53 characters, it (fortunately) drops off quickly after that.
There are only 2 things hard in programming, cache invalidation, naming things and off by one errors.
Personally I think this name is bad because in spite of the enormous length it still doesn't tell me what it actually does. It just uses a lot of characters to indicate its spot in a hierarchy.
Names like these are what gave rise to jokes like 'Q: What is the spelling of bureaucracy? A: J-a-v-a'. Which of course does a dis-service to java the language and the community behind it.
I can see why they're funny, but you have to realize that when you get out of the trivial program length domain into projects that are 100's of thousands of lines that this problem will sooner or later rear its ugly head. And I have not yet seen any really good solutions.
The things that can help you to extend your runway a bit in this respect are:
But even with those rules you'll have a 53 letter name in there somewhere... I'd be very wary of casting stones in situations like these without knowing exactly how the person that picked it originally made their choice. Chances are there were a whole pile of external factors dictating this monstrosity and the guy or girl (or the code generator!) that did it never was happy about it either. Laughing at others that have tackled some problem is easy. Coming up with real solutions and doing a better job of it is a lot harder.1) Most of us never tackle specific problem domains that are very rare
2) Most of us never come up with real world solutions
Most of us these days work on CRUD web-app with only a few who actually go deep into specific problem domains.
Sometimes the problem domains is just that hard. I know there are optimistic developers out there that keep saying "I can simplify this particular problem domains" but here we are in 2012 still writing CRUD web-app.
No. That is just wrong. There is no problem domain that requires the use of very long strings to refer to individual pieces of it. All systems, either statically or dynamically, can be decomposed into smaller pieces who's names are short because they are meaningful within the context of another name.
Or, to put it another way, you get names like this when you statically code a data-structure that should be dynamic.
or
public string Serialize(MessageHeader header)
or if you really want to get fancy Serialize<T>(GenericHeaderObject someObject) which would then be called as Serialize<MessageHeader>(header)
Then it'd be something like:
or shorter if you decided on utf8 across the board.I can only imagine the chaos if you start encoding a mixture of Latin-1 and UTF-8 headers :)
The other thing is that I prefer symmetry. I would probably write the function to take and return the same thing.
Finally, I might strongly consider writing a generic method that, using reflection, traverses arbitrary data structures and constructs an XML DOM. The caller can do what it needs, e.g. serialize into a string.
If, for some reason, your system requires a specific transformation from a custom data structure into a string, then it belongs in the custom data structure class - possibly a toString method, or something more specific.
orI still can't help the feeling that the data structure leaked into the naming of the function and I see no way to solve that, I can't even imagine how one would go about that and still have a function with global scope (in itself something that you'd try to avoid wherever you could, but in this case we can't for various good reasons).
I've looked at making this a generic system but that increases the overall complexity of the bookkeeping (creation, destruction, modification) around the objects to such an extent that it probably isn't worth it (though I can see some other advantages of this approach, such as easier debugging).
My point is still ultimately the same as others here, but I'm trying to demonstrate it from the other direction. It isn't that the long function name is OK, it is that it is poorly decomposed into tasks. But digging another "why" back, the root cause for that is what you say later, that it "increases the overall complexity of the bookkeeping" etc., and the reason for that is that C isn't really that good a language for abstraction. After 40 years of experience with it we've managed to create some best practices that carry it far further than anyone could have imagined at the beginning, but when it gets down to it, when you have a language that doesn't abstract very well, you do eventually end up paying the price in functions like that. It probably is the right answer in C, no sarcasm, but that's not the same thing as saying it's the right answer in a more general sense.
(And to be more concrete, C has poor facilities for composing abstractions together without complication and loss. On a feature-by-feature basis you can make it do pretty much anything you want, Turing Complete etc etc, which makes it hard to see in blog-post-sized examples, but they don't wire together very well.)
The linux kernel is actually only about 100 K lines. And its naming conventions are not what I'd call an example of elegance either, to put it very mildly (many of the names are quite cryptic and require extensive study of the code around it to understand what a function does). If low symbol length would be an indicator of code quality then we'd all be using fXXXX where X is a digit of your choice.
The longest symbol in the kernel proper that I can quickly locate is 36 characters:
It uses roughly the same convention that we use in our projects (a quite common one in large C projects): a module prefix (if possible the same as the filename) an action and a bit that specifies further details.Even with that simple convention it can add up quickly.
And if you start linking against 3rd party libraries you're going to be looking at name clashes sooner or later, even if you're careful. Whoever at mysql decided to expose 'list_free', 'list_add', 'list_delete' and so on with global scope wasn't having their most lucid day. I wished I was kidding.
This is what I get from sloccount, which doesn't count blank lines or comments, for Ubuntu's old 3.0.0 kernel:
Broken down by path (top 8): Overall I think your naming convention sounds reasonable; C is also my primary language. Your example was just too easy to shorten to resist ;-).That bit is the kernel. File systems, drivers and so on are best though of as plug-ins to the kernel. Architecture dependent code would probably normally expose only one set of symbols rather than all of the code, probably should have included memory management.
Likely if you include all that code you'll turn up a few more longish names, but the net effect is pretty much the same: really long names are rare when you've laid things out properly but 30 characters and up are certainly no exception.
edit: found a reference: http://www.drdobbs.com/cpp/extending-c-with-prolog/184409294
1. Static typing can help in reducing the function name.
2. Programming Languages give us means of combinations and abstractions in order to avoid that exact problem.
For example:
class RMG_Serialize inherits Serializor:
}The example is not perfect, the function is not exactly globally visible, but I could argue that instanciation of the class is available globally. Or you could get by, by making it static. Also, it's true that I'm adding more characters than any other function name, but no single word I wrote has more than 13 character keeping it easy to read. Every subsequent call to this function will be nothing more than `RMG_Serialize().utf8()`.
Imho, if you feel you're forced to give this kind of name to your variables, there's something wrong either with the design or with the specs.
The choice of programming language counts as well. I mentioned static typing as the obvious example, but isn't a language nothing more than a framework to name your variables?
But I agree with you that maintaining your names short is difficult. I think this has less to do with technical limitations and more to do with project management issues. Generally, I think that a team that understands the value of refactoring (and manage to afford it) will always be better at avoiding this crippling problem.
(Excuse me if I've mentioned this before.) So, I met the guy who did the first implementation of Merge Sort which he wrote in assembly language on paper tape. One of his comments on C++ after noting how cluttered it could look: "So, is this today's equivalent of COBOL?"
> when you get out of the trivial program length domain into projects that are 100's of thousands of lines that this problem will sooner or later rear its ugly head
Global namespaces are evil. We have non-global namespaces, but programmers keep on acting like there's only one global namespace. In reality, in large projects, everything should be considered relative to intersecting areas of concern, and code should always explicitly reference the libraries being used locally. Python could be used this way, but I suspect most programmers act as if imports are just a way of getting what they want into their most convenient namespace, which effectively becomes the global one.
:)
The embedded error is, of course, in itself off-by-one, but the actual cause could be cache invalidation -- the list was extended from two things to three without updating the length counter.
It also implements a specific interface Painter<JComponent> which explains the Why and the javadoc is copied from its parent class.
So it is not as much an example of beauraucracy as of code-generation.
Alternative would have been hundreds of "AnonN" identifiers with N going well into the hundreds...
Why then people keep creating long class names in the first place? I get it that this particular example might be a generated name, but still, why not just create package hierarchy that represents the code properly?
Also wouldn't using package hierarchies automatically lead to a bit better design (more modular, more understandable)?
There are java applications that have been around for decades. I've worked in codebases that are over twenty years old. Some of these systems are responsible for billions of dollars and have been heavily tested (the others are responsible for billions of dollars and have been barely tested).
Say you are a consultant, and you're working on a shipping application that has been around since the late 90's and is responsible for moving goods where the sum total of all items in transport over a year is larger than the GDP of Taiwan.
In that application there is a Warehouse interface. Simple thing, basically it has a receive() and distribute() method that moves product from one location to another (warehouse.receive(truck) or warehouse.distribute(200,truck)).
Around 2000 someone needed to create an edge case because specific warehouses are only available during specific times of the year. Like black Friday to Christmas. Usually it is too much overhead to keep all these warehouses running so they are only open 1/2 the year (this doesn't happen, but work with me). So someone created class TimedWarehouse that will do this calculation (on date X no longer receive).
Now it is 2012 and you are just a contractor. The big problem with the TimedWarehouse is at the end of the year you MUST VACATE ALL GOODS (because the warehouse is going to shut down). For the last couple of years product has been lingering in these warehouses keeping them open longer (costing more money).
The best way to handle this is perhaps a batch process job that sends emergency shipments as it gets closer to the end of the year. So something that cleans the timed warehouses out. Now you're just a consultant, you can't rework the entire framework but you must keep with convention... what to do
TimedWarehouseProcessor (nice... but doesn't indicate that it is only used towards the end of the year)
TimedWarehouseYearlyCleanout (makes more sense, but is terribly specific, what about warehouses that are open twice a year)
TimedWarehouseCleanoutManagementUtility (Bingo! More generic sounding, and it is a 'utility')
Imagine the poor sap who might need to extend that class. The process repeats over time. More contractors following the rules of convention, larger and larger class names.
AbstractTimedWarehouseCleanoutManagementUtility TimedWarehouseCleanoutManagementUtilityFactory TimedWarehouseCleanoutManagementUtilityConfiguration TimedWarehouseCleanoutManagementUtilityDto etc...
Maybe using underscores in class names would be nice, but then it gets ambiguous how to punctuate something, which gets annoying.
I don't understand what I'm supposed to take away from this. That there exists in the world badly named Java classes? And? Is the implication here that because you found an example of a clumsily named Java class the entire language is an usuable write-off? Or that it's somehow indicative of all Java applications?
I know Java isn't cool, but I don't see what is achieved by staring, pointing and giggling because you found an example of its use that is ungainly.
One can argue that this is the result of ignorance, that "good" Java programmers will avoid this trap. And yet, for all it's restrictions, it doesn't give much refactoring guidance. The proliferation of patterns (both for creation and relation) in Java is a weakness, not a strength, and the result is monstrosities like this. Training, experience and convention avoids these traps, but why do we create new languages if not to reduce the amount of training, experience and convention that a programmer needs to learn in order to be productive with an environment?
How many programmers have been affected by this internal class? How many programmers have used it and complain about it?
Java allows long identifier names and gives people the freedom to name however they like. Why is that a bad thing? You want syntax rules in the language to force short identifier names? We had those long while back and it's a really bad idea.
And BTW what is so wrong about imperative? It's simple to learn and simple to follow. It has solved many problems, given whatever the real world constraints. Just because functional is the in-thing now doesn't mean imperative is totally bad.
Nothing! The problems occur when people think that it's not.
And I really disagree with your hipster comment. You can indeed accomplish any task with Java, but that is damning with faint praise. The question is whether or not the environment gives the programmer adequate refactoring pressure to guide his decisions. Java provides almost no such pressure, resulting in a mess.
Many problems have been solved in Java despite of this, not because of it.
I don't really understand what you are trying to get at. Is it wrong or it isn't?
The hipster comment is spotted on. This post is evident of that attitude. The OP has to dig up an internal class whose name is probably generated to bash Java. And your original comment basically went further and claimed this long class name is the evident of what is so wrong with Java in general.
If there's no pressing pressure to refactor, then it has work well for its purpose. You want to limit class name to 8 characters to force programmers to pick shorter name? It's an internal class, for god sake. What's the impact on 99.99% of the programmer out there?
Development is a process of compromise and trade-off. Developers don't have infinite time and infinite budget to code. They have to pick their battle and do the more important things.
2. The phrase you're looking for is "spot on".
3. Generated code is a code smell. Again, you see a confusion between static and dynamic behavior.
2. Thank you for correcting my grammar. BTW the period goes inside the quotation marks as in "spot on."
3. While not often used, generated source code are useful as design calls for it. Not everything revolves around static and dynamic.
Now if you said "Module" or "Builder", then you might be right.
http://msdn.microsoft.com/en-us/library/aa432714(office.12)....