Tag Info

Hot answers tagged

23

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 ...


8

Step 1 - Source Control It is the most commonly accepted practice. It has been around forever, so avoids the "new fangled" argument. And it's hard to do worse than no source control. This can get your feet wet with a concrete success story to build off of. Step 2 - Knowledge Sharing The first training session shouldn't even be training. It should be ...


7

Am I doing it is right? If not what exactly I have to change It's hard to say just from that short description, but I suspect that, no, you are not doing it right. Note: I am not saying that what you are doing doesn't work or is in some way bad, but you are not doing TDD. The middle "D" means "Driven", the tests drive everything, the development ...


6

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 ...


6

Sometimes it's appropriate to add constructor to a struct and sometimes it is not. Adding constructor (any constructor) to a struct prevents using aggregate initializer on it. So if you add a default constructor, you'll also have to define non-default constructor initializing the values. But if you want to ensure that you always initialize all members, it ...


6

So I think you're working from a false premise. I believe you assume that if there are non-zero values in the memory space that was just allocated that the memory was somehow not properly allocated. And that's a horrific assumption that's going to burn you badly later on as you build more complex programs. Suffice it to say that the memory is being ...


6

I can see in a situation like that how forcing or preventing people to inherit or override makes sense, but in smaller programs I just don't see why or if these would be used. This ("Oh, it's just a small program that I alone am working on, and I know what I'm doing.") is a fallacy. There has been quite a bit of research done which has found that ...


5

You describe your development approach as a "top-down-only" process - you start from a higher abstraction level and go more and more into the details. TDD, at least in the form as it is popular, is a "bottom-up" technique. And for someone who is working mostly "top-down" it can be indeed very unusal to work "bottom-up". So, how can you bring more "TDD" ...


3

"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 ...


3

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 ...


3

Properties are syntactic sugar for approximating fields. They allow us to implement constraints or logic in our class while preserving the abstraction barrier of a POCO. The typical property in .NET does not change each time we "observe it". The semantics of auto-properties are clearly defined to use a compiler generated backing field, so properties should ...


3

Am I doing it is right? If not what exactly I have to change You're doing just fine. Is there any way you can identify whether test you have written are enough? Yes, use a test/code coverage tool. Martin Fowler offers some good advice on test coverage. Is it good practice to writing test for very simple functionality which might be equivalent ...


2

With C++11 you can do struct method { char name[32] = {}; float temperature = 42.141521; int duration = -6; }; And whenever you forget to initialize something, you get default initialization.


2

Writing tests first is a completely different approach to writing software. Tests are not only a tool of proper code functionality verification (they all pass) but the force that defines the design. While test coverage might be a useful metric, it must not be the goal in itself - the goal of TDD is not to get to a good % of code coverage, but to think about ...


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

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 ...


1

In my experience (and it's possible others will have other experiences), an application that modifies its own schema directly is usually a sign of a bad design, and it is probably unnecessary. I've yet to work on an application where the schema itself needed to change dynamically at runtime. If you start modifying your schema dynamically from your ...


1

Data definition language (DDL) statements are rarely used anywhere. Often, they are used in scripts that are processed by a SQL front end, initiated manually. However, programming the SQL front end requires that some Java (C, C++, what have you) programs are directly applying DDL on the database. Similarly, if you have a large application, it is often ...



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