4 ms·

Is misc.foo better than misc_foo? My point being - a point also raised by Joe - is that just "adding dots" doesn't solve anything.

• falcolas 15y ago
  I would rather have misc.foo (or in python terms, from misc import foo), than this_is_a_unique_function_name_that_does_foo, or '0000100302foo' with a ton of metadata to explain what it does and why it's better than every other similar function. I'm trying to imagine visually parsing a program where the function names are merely unique identifiers that don't necessarily relate to their function, and it's not going well.
  • seiji 15y ago
    The function names would still be user readable. The compiler and/or runtime would translate what you say to what you mean (think c++ mangling).
  • d0m 15y ago
    From what I understand, it'd be more: from global_database import foo291 as foo and you'd have lots of meta information associated to foo291 so you could easily find it by doing: db-search blah
  • bartonfink 15y ago
    <quote> I'm trying to imagine visually parsing a program where the function names are merely unique identifiers that don't necessarily relate to their function... </quote> Just to be pedantic: you're doing this already. int add(int a, int b){ return a - b; }
• haberman 15y ago
  > My point being - a point also raised by Joe - is that just "adding dots" doesn't solve anything. It's visually much easier to parse foo.bar_baz.quux than foo_bar_baz_quux. Also, It lets symbols inside the module call their friends by quux instead of foo_bar_baz_quux.
  • lelele 15y ago
    > Also, It lets symbols inside the module call their friends by quux instead of foo_bar_baz_quux. This is the main point in support of modules: they make you use names just like you are used to in real life. In a given context, shorter names suffice. When more contexts are involved, then you need qualifiers.