code-readability

I have just tried to lint some code with Pylint, and the last remaining error is R0902: too-many-instance-attributes (8/7) I understand the rationale behind limiting the number of instance attributes, but seven seems a bit low. I also realise that the linter should not have the last word. However, I would like to know what I should be doing instead of: def __init__(self, output_file=None, output_dir=None): """ Set the frobnicator up, along with default geometries """ self.margin = 30 self.pos = [0, 0] self.sep = [5, 5] self.cell = [20, 20] self.frobbr = library.Frobbr() page = self.frobbr.get

If you enable the "View Right Margin" in your IDE of choice, it is likely that it will default to 80 characters. I tend to change it to 120 for no reason other than it was the standard at a company I was with a few years back, and no other company has told me to do it differently. My question is, are there any studies that actually show 80 characters to be the optimal maximum width for code readability, or is this value just a "that's the way it's always been" and no one really knows why it is that way? And, should the width of a line of code be part of your coding standard? Actually, the 80

I'm trying to come up with an implementation for NotOfType , which has a readable call syntax. NotOfType should be the complement to OfType<T> and would consequently yield all elements that are not of type T My goal was to implement a method which would be called just like OfType<T> , like in the last line of this snippet: public abstract class Animal {} public class Monkey : Animal {} public class Giraffe : Animal {} public class Lion : Animal {} var monkey = new Monkey(); var giraffe = new Giraffe(); var lion = new Lion(); IEnumerable<Animal> animals = new Animal[] { monkey, giraffe, lion };

I have some topic to discuss. I have a fragment of code with 24 if s/ elif s. Operation is my own class that represents functionality similar to Enum . Here is a fragment of code: if operation == Operation.START: strategy = strategy_objects.StartObject() elif operation == Operation.STOP: strategy = strategy_objects.StopObject() elif operation == Operation.STATUS: strategy = strategy_objects.StatusObject() (...) I have concerns from readability point of view. Is is better to change it into 24 classes and use polymorphism ? I am not convinced that it will make my code maintainable... From one

I have been wondering for some time whether it is allowable within best practice to refrain from using the containsKey() method on java.util.Map and instead do a null check on the result from get() . My rationale is that it seems redundant to do the lookup of the value twice - first for the containsKey() and then again for get() . On the other hand it may be that most standard implementations of Map cache the last lookup or that the compiler can otherwise do away with the redundancy, and that for readability of the code it is preferable to maintain the containsKey() part. I would much

I'm new-ish to JavaScript. I understand many of the concepts of the language, I've been reading up on the prototype inheritance model, and I'm whetting my whistle with more and more interactive front-end stuff. It's an interesting language, but I'm always a bit turned off by the callback spaghetti that is typical of many non-trivial interaction models. Something that has always seemed strange to me is that in spite of the readability nightmare that is a nest of JavaScript nested callbacks, the one thing that I very rarely see in many examples and tutorials is the use of predefined named

Consider this line: if (object.getAttribute("someAttr").equals("true")) { // .... Obviously this line is a potential bug, the attribute might be null and we will get a NullPointerException . So we need to refactor it to one of two choices: First option: if ("true".equals(object.getAttribute("someAttr"))) { // .... Second option: String attr = object.getAttribute("someAttr"); if (attr != null) { if (attr.equals("true")) { // .... The first option is awkward to read but more concise, while the second one is clear in intent, but verbose. Which option do you prefer in terms of readability? I've

I have a question about idioms and readability, and there seems to be a clash of Python philosophies for this particular case: I want to build dictionary A from dictionary B. If a specific key does not exist in B, then do nothing and continue on. Which way is better? try: A["blah"] = B["blah"] except KeyError: pass or if "blah" in B: A["blah"] = B["blah"] "Do and ask for forgiveness" vs. "simplicity and explicitness". Which is better and why? Exceptions are not conditionals. The conditional version is clearer. That's natural: this is straightforward flow control, which is what conditionals are

Ultimately, code compiles down (eventually) into instructions for a CPU. Code, however, (in my humble opinion) is for human beings to read, update, and interact with. This leads me to the following observation: Code that is unreadable by other engineers, even if it's functional, is bad code. With that in mind, what can this programmer do to make code more easily read by humans? Naming Conventions? (Joel has a fair amount to say on that one) Code Structure/Layout? (please, for the love of god, don't get into the { placement debate) Phrasing? (Is it possible to write code that looks more like

I have a list comprehension which approximates to: [f(x) for x in l if f(x)] Where l is a list and f(x) is an expensive function which returns a list. I want to avoid evaluating f(x) twice for every non-empty occurance of f(x). Is there some way to save its output within the list comprehension? I could remove the final condition, generate the whole list and then prune it, but that seems wasteful. Edit : Two basic approaches have been suggested: An inner generator comprehension: [y for y in (f(x) for x in l) if y] or memoization. I think the inner generator comprehension is elegant for the