How the fuck did we went from too little chars for naming, to too many chars, and managed to keep the same fucking lack of sense???

How the fuck is that better?
Before we had 2 letters var names, and now we have to scroll right to read them, and it still has no fucking direct meaning!!!!

How the fuck createMongoServerClientConnection is a good fucking name?!?!?!?! It has no fucking meaning!!!!

  • 9
    It creates a connection to mongo 🤗

    But sure, maybe loose the server or client word so it actually makes sense which one it is.
  • 3
    Naming is hard.
  • 5
    Are you suggesting “createDBConnection” would be more useful? What name would you prefer instead?
  • 2
    @AmyShackles I'mc uriois as well. This one is "okay" considering the rest.

    So do tell us, JoJo!
  • 4
    @AmyShackles simple: to say WTF it does!

    If it createDbConnection, is it creating and object named BD Connection.... Or is it creating connecting to the DB?

    We don't say woodenExternalHouseProxy or externalHumanGateway but door!

    Adding words but resting meaning isn't a good tactics
  • 0
    I know right! It's fucking annoying. We need a middleground not to tame our variables dcn, but also not createMongoDBClientServerConnection

    @C0D4 there is just too much information in the name. createDBConn would be just enough, variable names shouldn't document the variable
  • 1
    Bay the way, it did not create shit... The function used a native sdk which created the client. So we had a DB.createClient function used inside the function....

    It so cargo cult!! The main idea to have longer names was to put meaning and intentions... Not more framework!!!
  • 2
    stable and descriptive names for functions and objects in code is great and all, but have you heard of javascript?

    js be like:
    function thisDoesAThingOrDoesIt => async () => { console.log("this literally does nothing")};
    module.exports = thisDoesAThingOrDoesIt

    const doSomething = require('mod') // aliased for 'API brevity'

    join us on the darker side of the force.js.
  • 1
    @noobrants oh, so you think it's only on is? let's be clear I like JS, for good and bad reasons, but I love Elixir.

    And I have reviewed python, java, go, rust, PHP, ruby done by none JS developers.
    And it's still shitty. Saying JS close is shitty because of the language is like saying your room is messy because the broom is shitty!

    And JAVA developers seems to buy characters for naming in bulk without the capacity to not use some....
  • 2
    also, sidecar: this is an argument for snake_case code style.

    create_mongo_client_server_connection forces you to admit you want to add 4 underscores to a single name. It looks wrong, on sight. camelCase lets you flowingly string together excessively long names and have that flaw blend into the background of the language.

    likewise, a snake_case convention explicitly discourages over-shortening your names to cdbc() by forcing you (in the "good practice code style" kind of way) to explicitly separate the words of your variable names with an underscore if they are meant to convey more than one word.

    connect_to_mongo. create_db_connection. read_csv. read_csv_s3. see how nice? join the snake_case gang.
  • 3
    @jotamontecino don't get me wrong, i write and like javascript - but it is very easy in JS - and frequently done - to fuck with people in the writing of your code by aliasing, indexing, re-exporting, etc due to the way JS handles modules and whatnot.

    I'm not saying my code is shitty because JS is shitty, I'm saying there's no constraints in JS that encourage more explicit and stable mechanisms for naming --- the kind of laissz-faire, write whatever however approach is convenient, but the cost of that convenience is standardized, readable code.

    Clearly, a good engineer with a head on their shoulders and a brain thinking about all of the audiences for their code can write beautiful, readable code in just about anything.

    Except lisp. we don't talk about lisp.
  • 1
    It gets even worse when you have nebulous shit with no relation to the actual problem domain made of any permutation of e.g. factory, manager, controller, handler, and service. To top it off, when you have different permutations in the same project.
  • 0
    Well look a the powershell lol

    Bad naming comes from poor architecture

    Use more classes and namespaces and things will look pretty
    Shorten the names, but not too much and use docstrings
  • 0
    @noobrants snake_case seems cleaner for me
    I always use snake for ordinary stuff
    But class names are CamelCase (PEP8)

    I personally benefit from this a lot
  • 2
    woodenExternalHouseProxy 🤣🤣🤣
    @jotamontecino, you just made my day with that comment!
  • 1
    @noobrants totally agree. And yes, one can find a very high wtf/line in JS...

    @sladuled now I'm starting to be afraid is I'll find this kind of shit with the IoT movement...
  • 2
    I would put it in a class/module/importable thingie called MongoDB, and name the method just simply connect, or getClient, or client.



    What parameters it requires, or what values it returns should not be in the name in my opinion. It might return a "connection", or a "client", or some kind of ORM querybuilder object. But good languages have types for that, which get shown in good code editors.

    In Rust, it would be something like this:

    use mongodb::Client

    use mongodb::bson::doc;

    Client::with_uri_str(url).await?.database("mydb").collection("penises").insert_one(doc! {"my_penis": 69 }, None)

    (Yeah devRant is not great with code examples)

    I would personally rename "with_uri_str" to "connect_to_url", but whatever.
Add Comment