Naming. One of the hardest things about software development :)
When I name something, here is my set of priorities:
- Follow the idioms of the language. Ruby likes underscores. JavaScript likes camel case. Whatever language you're in is the convention to follow.
- Reveal the intent of the API. It's not "send_http_data" it's "post_twitter_status".
- Avoid leaking implementation details. Say, prefixing a variable with a type.
- Do not use more characters than necessary without breaking the previous guidelines.
Obviously this is a rather simplistic approach. Naming is nuanced.
For further research, I would recommend reading The Art of Readable Code, as it provides some excellent, succinct advise on method naming. For even more research I cannot more highly recommend Bob Martin's Clean Code.
You will find that the developers themselves are not using short variable names. Whilst developing, they are using meaningful and detailed variable names.
Then, in the build/release process, the code they've written is ran through a minifier/obfuscator with the intention of minimizing the size of the file, as a best practise to speed up a website. This is an optional step if you care that much about performance. Most small websites don't do this.
You, as a developer, should not care about the minification/ obfuscation process; write your code so that it is readable, meaningful, well documented and well structured. Then if you care so much about performance (optional, don't forget!), introduce a minifier/ obfuscator into your release process to minize the code (remove white space, new lines, comments etc) and to obfuscate it (e.g. shorten variable names). A good article which explains obfuscation vs minification can be found here.
Additionally, Desktop FireFox will not truncate variable names period. The truncation of variable names is there to speed up the page download. By the time FireFox gets the file, it has already been downloaded therefore there is no need to do so. Your friend may run a plugin which is doing this; in which case, tell him to uninstall it, because it's useless.
For completion, some (mobile) browsers have the option to use middle-man servers, which intercept the responses of resources you requested, and compress them for you (which could include the minification of JavaScript files). Note that the compression is done on the server (i.e. before you have downloaded the page), hence the potential benefit of downloading a smaller file, rather than in the browser once you have already downloaded the file (as suggested in the question). Such mobile browsers include Opera Mini, and newer versions of Google Chrome (on iOS at least; not sure about Android). For more info, see here.
Best Answer
For C# you need only look at the conventions already in place within the .NET framework --- specifically the various
ParseandTryParsemethods.The
int.Parse(string)method throws aFormatExceptionif you pass it a string that cannot be parsed into a 32 bit integer.The
bool int.TryParse(string, out int)method returns false for every input that throws an exception when passed to theint.Parse(string)method.If your use case falls outside of these bounds, then you don't need to utilize this pattern, and in fact you might confuse other .NET developers who are already accustomed to this pattern.
If you
Findsomething, should it throw an exception or return null when the thing is not found? This, too, depends on the use case.If you try to find a key within a dictionary and there is no item with that key, it makes sense to throw an exception.
If you attempt to find a record in the database, where your code doesn't have the same level of control as it would with a Dictionary object, then throwing an exception will happen more often. Reserve exceptions for truly exceptional conditions (i.e. stuff that doesn't happen often and your code can't recover from).
If you are trying to find a record from a database or some sort of data store I would say it is more idiomatic to return a null value than throw an exception. If you are really worried about how other programmers might interpret a null pointer, then wrap it in another object that has a boolean property determining whether or not something was found.
A "find" method on a data access object returning a null pointer has never been a mystery to me, even as a novice programmer. I always knew it meant "the thing you tried to find was not found."