Tag Info

Hot answers tagged

27

No, it is not normal 1. At least, it's not normal for good programmers. It probably is normal for someone learning to program. Writing software isn't just slapping lines of code together until it works. You need to consciously work on making the code easy to understand. A programmer I respect highly once told me "code is read way more times than it is ...


14

There are two kinds of this: 1.) confusion 2.) blissful ignorance The first one is bad and may disappear with time and experience. The second is a good one if projects become larger: If you have to remember every implementation detail just to be able to work with your code, there's something wrong with it (see "information hiding"). Every developer is ...


9

I'd say it's more common than people care to admit. Even Brian Kernighan alluded to it: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. When we drive to the store, we make a sequence of detailed adjustments to the ...


7

Your problem isnĀ“t having a class with a constructor method, your problem is what you have put into it. Parsing a text file should not be part of the object - its job is to create and manage Simulations. The constructor/init method should take a simple list or map of particles as one of its parameters and use that data when initialising. Reading data from ...


5

I think this is something that'll go away with experience. If you're writing complex systems, you need to have the ability to write clean, maintainable code that both you in the future, and someone else in the future, can understand. So, in essence, the thing you're doing now isn't scalable. You'll have lots of moments where you're looking at some code you ...


4

"Normal" is very subjective, so I say: it is very common, but should be avoided. One of the features of "the good code" (I heard such thing exists) is clarity: it should be as clear as underlying problems allows it to be. If problem is complex, the code would be complex as well, but that's inherent complexity, as opposed to accidental complexity (I first ...


4

There is not a "right way", you have to choose when "promote" a fragment of code in a method. Usually it make sense create a new method: when your main method is too long, bloated or complex (code readability/maintainability) when that fragment is used two times or more (no code duplication) when that frament could be used from two methods or more (code ...


3

For discussion, I'm going to present a counter-argument to @itsbruce. YMMV. What is more likely to change, the file format or the object itself? (as in additional or changed fields). In my experience, if the file format is standard, and accessed through abstract interfaces (e.g. standard XML, JSON libraries), the core code for that doesn't change. It's ...


2

One of the reasons properties should never be "fancy" in terms of implementation, is they typically contain code that is executed in the debugger, in the watch windows and other places where variables can be viewed, such as tool tips. Methods are only executed on demand. Some types of "fancy" properties: Those that allocate memory when computing their ...


2

I don't think it is normal, but for very complex programs, like the chess program you mention, I think it certainly possible. Many years ago, when I was just out of grad school (so I was still relatively inexperienced writing large programs), I wrote my first real compiler. The parsing was straightforward, but then I needed to target it for four different ...


1

This is heavily dependent on your situation at hand. You don't give much surrounding context. Who are you writing this for? Is it a throwaway script to fulfil a specific need right now or do you intend for it to be used and maintained further on down the line? If you're writing it for yourself then you can do whatever you want, it's only you that will be ...


1

There are a lot of decent answers here. I have a couple of takes on this. One is that if you don't understand why your code seems to work, then a) it probably doesn't (it probably only seems like it works), and b) you either didn't understand the problem domain well enough when you started coding, or didn't break the problem domain down into smaller, ...


1

I wouldn't call it normal, but it can definitely happen. If it happens to you shortly after you wrote the piece of code in question, I guess that either your code is needlessly complex and should be simplified, or you're just easily distracted. :) But if you put your code away, concentrate on other projects, and return to it after weeks, months or even ...



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