in PHP, in production, I have seen a project where controllers always call the same function depending on some parameters.

Depending on the parameter, a different file is included, then the "doit()" function is called.

I can't tell you how much I hated debugging that thing!

I once spent two days debugging a typo in variable called smallIllustration. That's when I really started to like "snake_case".

I think the most important thing is to use descriptive names. I always try to use at least two words. In functions/methods, the first word should be a verb, e.g. publishArticle instead of just publish. In variables, there should be an adjective, e.g. filteredArticles instead of just articles.

This way, I can immediately see, without looking at the code around, distinction between functions and variables. I can also understand what kind of input the function expects and what kind of data the variable contains.

I have no beef against specific naming conventions (as long as they are consistently followed), but I somehow never got to appreciate operator overloading.

I have been learning F# recently and operator overloading here is a common practice :

In a popular web framework, this is how you do routing:

let app =
  choose
    [ GET >=> choose
        [ path "/hello" >=> OK "Hello GET"
          path "/goodbye" >=> OK "Good bye GET" ]
      POST >=> choose
        [ path "/hello" >=> OK "Hello POST"
          path "/goodbye" >=> OK "Good bye POST" ] ]

The "fish operator" is for kleisi composition.

Another interesting case from api documentation:

^^    : Search a list of key-value option pairs and return the value (or None if not found)

I have always felt that operator overloading destroys readability. It is disheartening to see even well-designed new languages like swift (touted as elegant) allowing this practice:

class MyFormViewController: FormViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        form = Section("Section1")
            <<< TextRow(){ row in
                row.title = "Text Row"
                row.placeholder = "Enter text here"
            }
            <<< PhoneRow(){
                $0.title = "Phone Row"
                $0.placeholder = "And numbers here"
            }
        +++ Section("Section2")
            <<< DateRow(){
                $0.title = "Date Row"
                $0.value = NSDate(timeIntervalSinceReferenceDate: 0)
            }
    }
}

Ruby has taken a very pragmatic approach towards this.

A very restricted form of operator overloading is allowed - so you can override how +, -, '<<' etc. behave for specific classes, but can not define new arbitrary operators.

---

I occasionally use a language called livescript which compiles to javascript. While the rest of the language is nice, succinct and compiles to readable javascript, a few eccentric design choices keep bugging me:

kebab-case and camelCase are interchangeable - and both compile to camelCase in javascript:

For example:

x.hasEntity! # the trailing bang implies invocation without arguments
x.has-entity!

both of the above compile to x.hasEntity().

Also we can use \x for 'x' (if string is just a single word). And this works for property accessors as well: x.\entity compiles to x['entity']. But obviously once you have a string the kebab-case to camel case conversion can not be reliably done.

So x.\has-entity! compiles to x['has-entity!']. Not only the kebab case conversion doesn't happen, the bang now is a part of string and there is no run time error and expected function is silently never invoked.

At one point this was a recurring source of bugs in my code.

There is the problem of poor naming convention, and then there is the problem of no name at all:

fn = (.schema.drop-table \users)

This defines a function with an implicit argument:

var fn = function(it){
  return it.schema.dropTable('users');
};

While this is useful in small callbacks, this can make code hard to read if overused.

This Quora answer is a funny example:

quora.com/What-are-some-cute-things-beginner-prog…

I'm primarily front end, and I see programmers mix camelCase and kebab-case (I love this name by the way, had never heard it before) in one selector! CSS classes should never be camelCase. For programming, I prefer camelCase. Other than that, I just prefer the naming convention to be consistent.

changing convention sucks the rest is childish ... who cares

• rust my_function_name
• c my_function_name
• java myFunctionName
• java MyClassName
• java myVariableName
• classic MY_CONSTANT_NAME

.... who cares .... functional elegance beats syntactic elegance always ... just stay consistent :)

Method names that are vague or lying - they say one thing and do something completely different

addWaterToCup() {
  // code that boils water, adds a portion of it to cup and adds a tea bag
}

Method names that doesn't really make sense

doExternalTeaBag() {

}

Method names that leak variable names or doesn't match the parameters when leaking params:

getEntityById(int id, int someotherid, int anotherfield){
  // do lookup on entity using all three params, but method name only mentions first param
}

This is also horrible, overloaded methods that simply call another method using internal params, I've seen several of these today.

class Abc {
  int a, b, c;

  doSomething(){
    doSomething(this.a, this.b, this.c)
  }

  doSomething(int a, int b, int c){
    // do something with a, b, c even though method has direct access to this.a,this.b and this.c
  }

}

I really hate hate hate hate hate snake_case. But you know, there are some things which are worse. Rust's mixture of snake_case and upper CamelCase and a lot more exotic things for example. Which poor creature, moaning of pain because of its birth, came up with that? I mean, like, REALLY? It's so random when to use what :/

The only case I like is lower camelCase. It's simple, readable, short.

What else do I hate? Well.... stuff like

var B = 'Hellow';
var ß = 'World';

and

int myvar = 42;
int myVar = 17;

Like... really? Or have you seen that?

var dothelongflopoversomehurdles = 34;
var dothelongflopontosomehurdles = 666;

OkOk, the one with the ß was taken from "how to secure a job for live" (or something like that). But I already found the other two in the wild. Scary.

What some people mostly follow:

public variable: myVariable / variable

private variable: myvariable / my_variable

public function: myFunction / function

private function: myfunction / function

local variable: *same as private var

parameters: *same as private var

What i do:

public variable: myVariable / Variable

private variable: my_variable / variable

public function: myFunction / Function

private function: my_function / function

local variable: _myVariable / _Variable

parameters: _my_variable / _variable

One can easily tell what scope does variable/function has, by just looking at the name. all categories have distinct representation

The snake_case is so old school. kebab-case isn't much better either, but at least the name is fun :D

For me puting a underscore ( _ ), or two before the method name to say it's private it's a bad practise.

For other side, putting underscore_lower_case name at variables i don't like so much. Or make the code so near between lines that make difficult to understand the logic.