conventions

At work, we place braces on the next line, but at home, I do the opposite. Which one do you prefer? (K&R vs OTBS) function something() { // ... } function something() { // ... } A lot of JavaScript libraries seem to use the OTBS (one true brace style). I'd like to follow them for consistence among other JavaScript projects, but doesn't K&R style look more readable? Note: We know the problem with return and braces in JavaScript, that will always be an exception. However, that is only a single case. This is a Holy War to which you will never get a usable answer! Just stick with whatever everyone

PEP 8 says: Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants. On occation, I violate PEP 8. Some times I import stuff inside functions. As a general rule, I do this if there is an import that is only used within a single function. Any opinions? EDIT (the reason I feel importing in functions can be a good idea): Main reason: It can make the code clearer. When looking at the code of a function I might ask myself: "What is function/class xxx?" (xxx being used inside the function). If I have all my imports at the

I've got a large-ish class (40 or so methods) that is part of a package I will be submitting as course-work. Currently, the methods are pretty jumbled up in terms of utility public/private etc. and I want to order them in a sensible way. Is there a standard way of doing this? E.g. normally fields are listed before methods, the constructor(s) are listed before other methods, and getters/setters last; what about the remaining methods? Some conventions list all the public methods first, and then all the private ones - that means it's easy to separate the API from the implementation, even when

I very rarely meet any other programmers! My thought when I first saw the token was "implies that" since that's what it would read it as in a mathematical proof but that clearly isn't its sense. So how do I say or read "=>" as in:- IEnumerable<Person> Adults = people.Where(p => p.Age > 16) Or is there even an agreed way of saying it? I usually say 'such that' when reading that operator. In your example, p => p.Age > 16 reads as "P, such that p.Age is greater than 16." In fact, I asked this very question on the official linq pre-release forums, and Anders Hejlsberg responded by saying I usually

The Spring Framework API doc says: The convention used is to return the uncapitalized short name of the Class, according to JavaBeans property naming rules: So, com.myapp.Product becomes product; com.myapp.MyProduct becomes myProduct; com.myapp.UKProduct becomes UKProduct. I looked at Suns website to find a definition, but didn't find one. I wonder about a rule for names with more than one upper case character at the beginning. Is the rule that the first character is upper case if the second character is upper case too? The background is, that I want to generate variable names automatically

Is there a python convention for when you should implement __str__() versus __unicode__() . I've seen classes override __unicode__() more frequently than __str__() but it doesn't appear to be consistent. Are there specific rules when it is better to implement one versus the other? Is it necessary/good practice to implement both? __str__() is the old method -- it returns bytes. __unicode__() is the new, preferred method -- it returns characters. The names are a bit confusing, but in 2.x we're stuck with them for compatibility reasons. Generally, you should put all your string formatting in _