coding-style

Is it advantageous to call logging functions with format string + args list vs. formatting inline? I've seen (and written) logging code that uses inline string formatting: logging.warn("%s %s %s" % (arg1, arg2, arg3)) and yet I assume it's better (performance-wise, and more idiomatic) to use: logging.warn("%s %s %s", arg1, arg2, arg3) because the second form avoids string formatting operations prior to invoking the logging function. If the current logging level would filter out the log message, no formatting is necessary, reducing computing time and memory allocations. Am I on the right track

I prefer to use local variables rather than multiple calls to the same method. /* * I prefer this */ Vehicle vehicle = person.getVehicle() if (vehicle instanceof Car) { Car car = (Car) vehicle; car.openSunroof(); } else if (vehicle instanceof Bike) { Bike bike = (Bike) vehicle; bike.foldKickstand(); } /* * Rather than this */ if (person.getVehicle() instanceof Car) { Car car = (Car) person.getVehicle(); car.openSunroof(); } else if (person.getVehicle() instanceof Bike) { Bike bike = (Bike) person.getVehicle(); bike.foldKickstand(); } I believe that the first way is going to perform a tiny bit

Is there a Checkstyle rule file with the Google Java Style ? The checkstyle team added it several days ago. Here it is : https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml Markus Schulte If you have a maven-project, you can easily integrate google_checks (you have to use at least maven-checkstyle-plugin version 2.17) <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-checkstyle-plugin</artifactId> <version>2.17</version> <configuration> <configLocation>google_checks.xml</configLocation> </configuration> </plugin> Executing checkstyle

This is a question about conventions. The two sets of commands below return identical results. a = [1, 2, 3] a.first # => 1 a[0] # => 1 a.last # => 3 a[-1] # => 3 Which of these is preferred in Ruby, the explicit index or the functions? Assuming, of course, that this is in code which always accesses the first or last element. Note: I've been thinking about the cycles each would take. Because first and last accept parameters, they will have a little more overhead, but I don't know if that affects what the community prefers. Thanks! EDIT If you read the comments on this post, there was a big

I have a jade variable declared like this: BUTTONS = { more_blue: {caption: BUTTONS_CAPTIONS.more, style: BUTTONS_STYLES.blue}, more_red: {caption: BUTTONS_CAPTIONS.more, style: BUTTONS_STYLES.red}, see: {caption: BUTTONS_CAPTIONS.see, style: BUTTON_STYLE_PHOTOS}, see_photos: {caption: BUTTONS_CAPTIONS.see_photos, style: BUTTON_STYLE_PHOTOS}, program : {caption: BUTTONS_CAPTIONS.program, style: BUTTON_STYLE_PROGRAM}, see_program : {caption: BUTTONS_CAPTIONS.see_program, style: BUTTON_STYLE_PROGRAM} } but I would like it to be more readable like this: BUTTONS = { more_blue: {caption: BUTTONS

This question already has answers here : Closed 9 years ago . Possible Duplicate: Should ‘else’ be kept or dropped in cases where it’s not needed? When a = 0 This: var foo = function() { if (a != 0) return true return false } Or this: var bar = function() { if (a != 0) return true else return false } It gets optimized at compile time anyway, so no runtime difference. As usual, you can argue about style. My 50 cents: the first variant (no explicit else) is nicer because it's less code doing exactly the same. Of course, in this case, you would do return a != 0; ... but I think the question is

This question is only half tongue-in-cheek. I sometimes dream of a world without naked arrays or c strings. If you're using c++, shouldn't the preferred definition of main be something like: int main(std::vector<std::string> args) ? There are already multiple definitions of main to choose from, why isn't there a version that is in the spirit of C++? A concern that keeps coming back to my mind is that once you allow complex types, you end up with the risk of exceptions being thrown in the type's constructor. And, as the language is currently designed, there's absolutely no way for such an

Where can I get the complete list of JSHint default options. I tried searching online but couldn't find anything. EDIT: I mean a list of default values for all options, in case it wasn't clear :) Mikhail Chernykh You can look on boolOptions , valOptions and invertedOptions objects directly in jshint sources: https://github.com/jshint/jshint/blob/master/examples/.jshintrc If you are confused with comments, you can refer to options section in jshint help: http://jshint.com/docs/options/ J.D. Actually, that page contains the list of default options, and that file mentioned in @netme's answer has