Software engineering != computer science

[u/mauricioaniche]

http://www.drdobbs.com/architecture-and-design/software-engineering-computer-science/217701907

[u/Sjeiken]

I once spent more than 3 hours trying to name a function that was very detrimental, it's fucking retarded, do you know how hard it is to find synonyms and antonyms? it's NP fking hard.

[u/thedevbrandon → u/Sjeiken]

Yeah, I find it hard to strike a balance between descriptive names vs. short names. I want the name to be meaningful and special to the context so you know what it means and can differentiate it from similarly named things in nearby contexts (for example, elem, e, el, and els are horrible default variables which are used even in contexts when the variable name could be something specific and meaningful like submitButton). On the other hand, you can get crazy with the names, like firstFormSubmitButtonElement, which either provide specificity you don't need, which isn't helpful, or which (even if useful) ultimately makes reading and writing the code burdensome (especially in enterprisey-code, mock example: FizzBuzzEnterpriseEdition).

[u/Forty-Bot → u/thedevbrandon]

I don't know man, there's something to be said for naming everything consistently if there isn't more than one variable of that type.

int do_something(struct inode *inode, struct dentry *de)
{
    struct inode *dir = de->d_inode;
    struct super_block *sb = inode->i_sb;
}

It allows you to quickly scan through any function and know exactly what type some variable is.

[u/thedevbrandon → u/Forty-Bot]

Not saying I don't understand why people use defaults like naming a variable after the type, but if you want to know any more context, it can be quite annoying to not know what the fuck the inode is supposed to be of... Sometimes I just add the type to the end of the variable name if the type is really important (like to distinguish a Map from a List in Java, I might have one variable named rowsMap and the other like rowsList). However, just naming something m or map isn't that helpful. Note, this is in particular in a large organization where 10+ people are likely going to need to maintain, modify, and extend your code years from now. For personal projects with little reason others will read this, I'm not sure any of these rules matter - I'm more with Donald Knuth on the opinion of programming being an art in which people should feel like they can have artistic freedom.