Thursday, October 19, 2017

Cases for Cases

Today a coworker made his argument against using snake case for our projects:
some_function(...)

He wants us to use camel case in Javascript fashion:
someFunction(...)

His reasoning was snake case requires hitting the Shift key to get the underscores. In my personal projects I typically use a hybrid of pascal case and snake case:
Some_OtherFunction(...)

I find snake case much more readable, however in some cases combining that with pascal eliminates excessive underscores while logically grouping the method names etc.
 
The hole in his argument is that uppercase letters also require the use of the Shift key (It does require an extra character so he has a partially valid point). It seems to me if we want to avoid Shift we would need to use spinal case:
some-function(...)

I differ with the Javascript people in that I think readability is key. If you look at Javascript code, clearly they couldn't care less about readability. Have you ever tried reading through levels and levels of anonymous functions? Good times.
Anyway, I believe that readability is more important than avoiding the need to hit the shift key. Ultimately someone else is most likely going to have to deal with your code, help them out.

4 comments:

  1. I always capitalize the 2nd word and avoid using dashes or underscores at all. If all else fails, you should always have good comments throughout all the lines so anyone can see exactly what everything does. I find it useful even for going back to work on some of my old code, because there have been times I've looked at old code thought "What exactly was I doing here?".

    It's also worth mentioning the possibility of errors when working internationally online with (old) unicode characters, where there are several different "hyphen/minus/dash" characters. Although this is less of an issue with modern text encoding.

    ./d

    ReplyDelete
  2. I whole-heartedly agree with the comments about comments! At work where we have not-so-intuitive or self explanatory (in looking at the code) business rules, my team writes extensive comments explaining the rules. So documentation is right there in the source.
    Caps and stuff, I have a mild preference but whatever the team etc want. I don't even care. Hehe

    ReplyDelete
    Replies
    1. Yes, whichever route you take, just be consistent. Even more important that everyone in a team do the same. :)

      ./d

      Delete

From Shotcut to Kdenlive

So I've been using Shotcut for a while now, for my YouTube videos... and music videos. I love the application. Slicing clips, doing fade...