4 ms·

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)

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.

javajosh 14y ago
>Sometimes the problem domains is just that hard. 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.
- jacquesm 14y ago
  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?
  - voltagex_ 14y ago
    public string SerializeMessageHeader(string messageHeader) 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)
  - anthonyb 14y ago
    Why do you have to call it anything? Why isn't it a method or attribute on a RouterMessage object? Then it'd be something like: RouterMessage.utf8_xml_header or shorter if you decided on utf8 across the board.
    - erikpukinskis 14y ago
      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.
      - anthonyb 14y ago
        Probably likely to be an attribute on the RouterMessage, or a dependency injection, or a configuration setting somewhere. I can only imagine the chaos if you start encoding a mixture of Latin-1 and UTF-8 headers :)
    - mercurial 14y ago
      But then you're tying your business object to your serialization system, while they ought to live in distinct layers.
      - anthonyb 14y ago
        Except that then your serialisation system has to handle arbitrary objects, which may not be what you want.
  - javajosh 14y ago
    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. RouterMessageHeader.toXMLString(); or XMLSerializer.stringify(routerMessageHeader);
    - jacquesm 14y ago
      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).
      - javajosh 14y ago
        You probably won't see RouterMessageHeader.toXMLString() in the calling code though. You'd see: RouterMessageHeader foo = new RouterMessageHeader(); foo.toXMLString(); There are other ways for foo to be derived, of course, and in many of them you never need to reference the ReferenceMessageHeader class name.
      - deleted 14y ago
  - nitrogen 14y ago
    I think it's acceptable to leave details like character encoding in the documentation, so: msghead_to_xml() Are there any 53-character function names in the multi-million line Linux kernel?
    - jacquesm 14y ago
      > 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.
      - nitrogen 14y ago
        The linux kernel is actually only about 100 K lines. This is what I get from sloccount, which doesn't count blank lines or comments, for Ubuntu's old 3.0.0 kernel: Totals grouped by language (dominant language first): ansic: 9495321 (96.81%) asm: 241006 (2.46%) xml: 41486 (0.42%) perl: 13987 (0.14%) sh: 4117 (0.04%) cpp: 3486 (0.04%) yacc: 2987 (0.03%) python: 2770 (0.03%) lex: 1719 (0.02%) awk: 708 (0.01%) pascal: 231 (0.00%) lisp: 218 (0.00%) sed: 30 (0.00%) Broken down by path (top 8): SLOC Directory SLOC-by-Language (Sorted) 5474678 drivers ansic=5469921,yacc=1688,asm=1475,perl=792,lex=779, sh=23 1848085 arch ansic=1609109,asm=237452,sh=690,awk=470,pascal=231, perl=58,python=45,sed=30 693955 fs ansic=693955 518275 sound ansic=518092,asm=183 481158 net ansic=481062,awk=96 290060 include ansic=288348,cpp=1670,asm=42 118198 kernel ansic=117893,perl=305 53773 mm ansic=53773 Overall I think your naming convention sounds reasonable; C is also my primary language. Your example was just too easy to shorten to resist ;-).
  - babarock 14y ago
    There are two things I can think of: 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: router_msg_header rmg xml_utf8 utf8() { ... super(this.rmg) ... } } 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.
michaelfeathers 14y ago
The tragedy is that it happened in a language with packages (i.e., namespaces).

javajosh 14y ago

>Sometimes the problem domains is just that hard. 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.

jacquesm 14y ago
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?
- voltagex_ 14y ago
  public string SerializeMessageHeader(string messageHeader) 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)
- anthonyb 14y ago
  Why do you have to call it anything? Why isn't it a method or attribute on a RouterMessage object? Then it'd be something like: RouterMessage.utf8_xml_header or shorter if you decided on utf8 across the board.
  - erikpukinskis 14y ago
    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.
    - anthonyb 14y ago
      Probably likely to be an attribute on the RouterMessage, or a dependency injection, or a configuration setting somewhere. I can only imagine the chaos if you start encoding a mixture of Latin-1 and UTF-8 headers :)
  - mercurial 14y ago
    But then you're tying your business object to your serialization system, while they ought to live in distinct layers.
    - anthonyb 14y ago
      Except that then your serialisation system has to handle arbitrary objects, which may not be what you want.
- javajosh 14y ago
  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. RouterMessageHeader.toXMLString(); or XMLSerializer.stringify(routerMessageHeader);
  - jacquesm 14y ago
    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).
    - javajosh 14y ago
      You probably won't see RouterMessageHeader.toXMLString() in the calling code though. You'd see: RouterMessageHeader foo = new RouterMessageHeader(); foo.toXMLString(); There are other ways for foo to be derived, of course, and in many of them you never need to reference the ReferenceMessageHeader class name.
    - deleted 14y ago
- nitrogen 14y ago
  I think it's acceptable to leave details like character encoding in the documentation, so: msghead_to_xml() Are there any 53-character function names in the multi-million line Linux kernel?
  - jacquesm 14y ago
    > 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.
    - nitrogen 14y ago
      The linux kernel is actually only about 100 K lines. This is what I get from sloccount, which doesn't count blank lines or comments, for Ubuntu's old 3.0.0 kernel: Totals grouped by language (dominant language first): ansic: 9495321 (96.81%) asm: 241006 (2.46%) xml: 41486 (0.42%) perl: 13987 (0.14%) sh: 4117 (0.04%) cpp: 3486 (0.04%) yacc: 2987 (0.03%) python: 2770 (0.03%) lex: 1719 (0.02%) awk: 708 (0.01%) pascal: 231 (0.00%) lisp: 218 (0.00%) sed: 30 (0.00%) Broken down by path (top 8): SLOC Directory SLOC-by-Language (Sorted) 5474678 drivers ansic=5469921,yacc=1688,asm=1475,perl=792,lex=779, sh=23 1848085 arch ansic=1609109,asm=237452,sh=690,awk=470,pascal=231, perl=58,python=45,sed=30 693955 fs ansic=693955 518275 sound ansic=518092,asm=183 481158 net ansic=481062,awk=96 290060 include ansic=288348,cpp=1670,asm=42 118198 kernel ansic=117893,perl=305 53773 mm ansic=53773 Overall I think your naming convention sounds reasonable; C is also my primary language. Your example was just too easy to shorten to resist ;-).
- babarock 14y ago
  There are two things I can think of: 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: router_msg_header rmg xml_utf8 utf8() { ... super(this.rmg) ... } } 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.

michaelfeathers 14y ago

The tragedy is that it happened in a language with packages (i.e., namespaces).