Tag Info

Hot answers tagged

181

Protected variables should be avoided because: They tend to lead to YAGNI issues. Unless you have a descendant class that actually does stuff with the protected member, make it private. They tend to lead to LSP issues. Protected variables generally have some intrinsic invariance associated with them (or else they'd be public). Inheritors then need to ...


71

I believe you are looking at the problem the wrong way - you are missing a great opportunity of teaching the juniors how to write better code. If you habitually re-write their code, you might give your juniors the impression that you don't value their work, which will lower their morale, and not help them code better the next time. A better approach, I ...


45

Sounds like a good habit to me. First rule in coding is to make it work. Once you've done that, clean up your code and make it neat, understandable and simpler if you can. However - if you are spending a lot of time over designing your solution and wasting a lot of time creating stuff that doesn't need to exist, that's possibly a bad habit - like if you ...


38

In general: use it. Write a test for your function, a real world test. Something you would actually like to do with that function. And see in what order you did put those down. Unless you already have (or know of) some functions that do something similar. In that case: conform to what they do already, at least for the first arguments. e.g. Do they all ...


35

It's really the same reason you avoid globals, just on a smaller scale. It's because it's hard to find everywhere a variable is being read, or worse, written to, and hard to make the usage consistent. If the usage is limited, like being written in one obvious place in the derived class and read in one obvious place in the base class, then protected ...


32

Just the single field being used for the lookup. The caller doesn't have a Foo, it's trying to get one. Sure, you can make a temporary Foo with all other fields left blank, but that only works for trivial data structures. Most objects have invariants that would be violated by the mostly-empty-object approach, so avoid it.


31

For a start the rule says "probably", so it doesn't always apply. The second point I see here is that if you have to declare one of the three, that's because it's doing something special like allocating memory. In this case, the others wouldn't be empty since they would have to handle the same task (such as copying the content of dynamically allocated ...


29

I have said this before and will say it again "working code is more valuable than pretty code". If you change code the chances are high that you will change its behavior, if this is tested code then you have just invalidated all the testing effort, and will need to repeat the tests. By all means encourage your juniors to write clean understandable code, ...


28

Use an auto-formatter. If you really are spending that much time manually editting the code, I would be willing to guess you are not very challenged/bored, because there is absolutely no reason for it. Ctrl+K, Cntrl+D in VS will format an entire document. You can use something like Style Cop if you want something a bit more heavyweight. It is good to have ...


27

The simple answer is that you really can't prevent code duplication. You can however "fix it" through a difficult continuous repetitive incremental process that boils down into two steps: Step 1. Start writing tests on legacy code (preferably using a testing framework) Step 2. Rewrite/refactor the code that is duplicated using what you've learnt from the ...


26

Always err on the side of a readable client ... GetWebDriver("IE", true) or GetRemoteWebDriver("IE") It seems self-evident to me which one is easier to read. Of course, another option would be GetWebDriver("IE", DriverType.Remote) Which is equally readable, but I wouldn't go down that road unless there are likely to be more than two options.


23

In my experience, making new code clean is actually not that difficult. Typically you have a single clean concept in your mind about what the code is supposed to do, how to implement it etc. so it is fairly easy to arrange the code to reflect this one thing clearly (a least according to one's current understanding - returning to the same piece of code 6 ...


23

My experience: A piece of code longer than 20 lines, written as a proof-of-concept, will not get re-written when the concept thus proved is needed, but rather bent to somewhat fit the needs of the production code. Usually, this goes with the promise to re-write it later, when there is time to do it all properly. However, this time never comes, so this ...


23

From experience: TDD does not necessarily lead to good design. It's possible and really easy to get poorly designed program using TDD. TDD is just a tool to help us design faster using refactoring, it will never make the design of the program appear magically. TDD is a design help tool. The quality of the design you will get out of TDD depend largely on ...


21

I can give you one example from my experience. About 10 or 12 years ago I inherited an application from a team of developers that ended up leaving the company (too long to get into here...). The system was a large home-grown middleware report generation system. It ran every week night and generated about 2 dozen Excel reports for senior executives of a ...


20

Prioritize. First things first. Focus on what matters. Your priorities may vary, but in general you should care about: Correct code Maintainable code Clean code Simple, elegant code Efficient code Maybe in that order. However, the first point is the most important. Without it, code is useless. What do you do with a program which doesn't work correctly? ...


20

My answer may be little off topic, but this method works for me. Before you even start programming you have to think: what kind of structures I need to solve a problem, and what kind of algorithms. Often you will find that solution already exist and that you only have to implement it into your project*. Never try to reinvent a wheel - if you need ...


18

Firstly I'd like to point out that unit tests are not a replacement for integration tests. The two need to exist side-by-side. Be grateful that you have integration tests, otherwise one of your small refactorings could well make one of the low-tolerance cash cows go ballistic on you. I would start to work on the compiler warnings and unused variables and ...


18

I haven't read the book, but I can take a stab at what Uncle Bob meant. If you put protected on something, that means that a class can inherit it. But member variables are supposed to belong to the class in which they are contained; this is part of basic encapsulation. Putting protected on a member variable breaks encapsulation because now a derived class ...


17

The problem here is the signature of setLocation. It's stringly typed. To elaborate: Why would it expect String? A String represents any kind of textual data. It can potentially be anything but a valid location. In fact, this poses a question: what is a location? How do I know without looking into your code? If it were a URL than I would know a lot more ...


16

Lets face it. "Software rot" is not a well-defined technical concept. It is more of a pejorative description of what happens when software is poorly maintained. The Wikipedia page represents one view, but there are clearly alternative views. And you could say that the different views reflect the different priorities and concerns of the person holding the ...


16

Optimizing for readability, I'd choose the first option for the public interface: The intent of GetRemoteWebDriver("IE") is more obvious than GetWebDriver("IE", true). Of course, from an implementation point of view, it might make sense for both GetWebDriver(string) and GetRemoteWebDriver(string) to call private GetWebDriverImpl(string, bool).


15

Demeter's law is a design guideline, not a law to be followed religiously. If you feel that your classes are enough decoupled than there's nothing wrong with the line this.configuration.getLocation() especially if, as you say, it is impractical to change other parts of the API. I'm pretty sure that the client will be perfectly happy even if you make the ...


15

The short answer is: no. When times are hard, sometimes you just have to put your head down and take the aesthetic bullet. ;) A more pragmatic answer is to time-box it. Budget an hour to run through and clean up one specific aspect of the code. Then check it in and do some real work. But be honest with yourself about keeping it constrained. Sometimes, ...


14

I recently had to implement a firmware programmer using the Motorola S-record format, very similar to what you describe. Since we had some time pressure, my first draft ignored redundancies and made simplifications based on the subset I actually needed to use in my application. It passed my tests easily, but failed hard as soon as someone else tried it. ...


14

This is an excedingly common practice and the way of dealing with it is via higher-order filters. Essentially, you pass a function to the filter method, along with the list/sequence that you want to filter against and the resulting list/sequence contains only those elements that you want. I'm unfamiliar with python syntax (though, it does contain such a ...


14

The danger with refactoring generated code to clearn and tidy it is that if it is regenerated again by the tool by yourself or another developer then the changes would be lost. Your team could get yourselves in a position where you would be generating the code in another file and copying it into the cleaned version and refactoring to apply changes which ...


13

If you've got legacy code I think it's often pragmatic to clean-up or refactor code when there's a need to dive into that code e.g. to fix a bug or add a new feature. Otherwise you risk wasting time or breaking code that was never going to be maintained again anyway. I wouldn't usually dedicate time to cleaning up code for the sake of it but rather while ...


13

I usually go with these rules, though not always with the same precedence. I guess it's an automatic thought-process now, and I don't over-think it, except for public API design. Selection Funnel Semantics Importance / Relevance Frequency of Use I/O Concerns 1. Semantics First Especially in OOP, pick parameters based on their semantical significance ...


13

What you need to understand is that no company sets out to write mediocre code. The problem is that 50% of the code, give or take, is written by the below average programmers of your company. You're preaching to the choir when you expound the benefits of clean code. The trick is how to do it. Do some research on things like peer review tools, static ...



Only top voted, non community-wiki answers of a minimum length are eligible