32
oztek
6y

my team mate thinks that function name should be descriptive so you can understand what It will do.
Here are the examples of functions he created:

createArrayOfConsentChangedEventObjectForAConsentForAllDataProcessorsWithoutNameInEvent()

createArrayOfConsentChangedEventObjectForAConsentForAllDataProcessorsWithNameInEvent()

createAndPushConsentChangedEventWithAndWithoutNameForAParticularConsent()

I was supposed to review his code but this names are so annoying that I gave up on reviewing and just passed his code since functionalities were working as expected. -_-

Am I the only one who gets annoyed by long function names?

Comments
  • 13
    Yes to creating a good, clear and describable method naming

    No to what ever the fuck he/she is doing
  • 6
    I'd tell him to fuck off and write that shit into the docs. Choose a name that be spoken within one normal breath.
  • 3
    @Awlex exactly my point. That co worker is a good frnd of mine so I shared link of this rant with him so dw, he will get your message 😂
  • 1
    In the language I programm, the limit of all names (classes, methods, variables) is 30 chars and this is also sometimes really annoying. But you get very creative to find good names...
  • 1
    Overdoing something is a problem too bro.
  • 0
    Your friend will like Objective-C then.
  • 0
    OMG! WTF?!
  • 0
    I’m ALL about descriptive naming conventions... but this is beyond verbose.
  • 1
    Has (s)he added comments to each one of them too, if the answer is yes, then there's no excuse for names to be so long. There should be no more than 5 words in a single method name, otherwise it becomes too long to read and understand. That's why comments were invented to add description to the code. Also did he ever hear about polymorphism and/or overloads? Such long names make it impossible to work with if he writes polymorphic code and/or uses overloads.
  • 1
    Ask the dude to use snake case if readability is the objective.

    Camel case is for 3 words at most. Generally.
  • 3
    Joke's on you because you're going to have to maintain that code. I would NEVER approve that.
  • 3
    Like @muliyul said, since you approved it, you're just as guilty.

    What I would have done :
    talk to the guy
    Put up a linter and a variable / function name limit
    Asked him to fix every error

    Alternatively : go nuclear
    Write your code in a single function name then parse & eval the name.
  • 1
    @Commodore I like the second option 👹
  • 0
    Function names shoild be descriptive for sure, but these names are too long and it is a waste of time and a hassle to read. Ask him to use shorter names and do some code comments to explain the functions, this is how it is supposed to work ...
  • 1
    @Commodore 🤣🤣
    Third option : teach him abojt code comments, code docs and descriptions
  • 1
    @Debugmed that's what I had in mind by "by talk to him". (which is quite ironic : being too vague in a rant about someone too explicit 😋)

    Anyway the idea was:
    1. Teach
    2. Setup safeguards
    3. Put in practice
  • 0
    @Commodore good luck 😋🤞👍
  • 1
    Maybe tell him about comments?
  • 0
    @vlatkozelka

    you get used to it lol. It's Cocoa classes is where things get wonky. Like how you simply can't add primitives to arrays (NSArrays, to be exact), you'll need to wrap them in their appropriate nullable objects, i.e. int/doubles/floats/booleans go to NSNumber, strings go to NSString, raw byte data buffers must be in NSData, structs must be wrapped in NSValue, and so on.
Add Comment