3 ms·

I said that it is a rough estimate, and we can tweak the formula. My opinion is that programmer competence is not absolute, but also not terribly relative. I me

by nadam 14y ago

I said that it is a rough estimate, and we can tweak the formula. My opinion is that programmer competence is not absolute, but also not terribly relative. I mean John Carmack is kind of absolutely a better developer than let's say junior average Joe. >small size of code means almost nothing to anyone except the original developers. No. Small size reflects the quality of the code: It reduces the time of future developments (non DRY code keeps growing agreessively and becomes even more non DRY and very time consuming to develop new features into). It is an investment in the future. Now you are right: sometimes it is not worth it to invest into the future, because maybe the code will be thrown away because it will turn out that the startup/product is not viable. Somtimes you know that product has a stable growing market and you will have to develop tons of features into it in the future. Then investing in the future is very important.

randomdata 14y ago
I think I understand where you are coming from, but DRY tends to, at least initially, increase the size of codebases and development time. The programmer who hacks something together that works now, but is a nightmare to maintain later will score better in your formula. As you say, it is an investment in the future, which implies that you are giving something up now for something more later.
mercurial 14y ago
> Small size reflects the quality of the code. Not always. Case in point: a week or two ago, I refactored some C# code. It was an installer generator, which was coded entirely in the controller. Yeh who want to add unit tests, abandon all hopes. So the code is now split into different pieces, according to responsibilities, with dependency injection, and I/O in its own layer. The result, in terms of lines of code, is a net increase. But according to your metric, I have decreased the quality of the code. I agree that generally speaking, less code is better than more code, but more code can mean reusable, more readable code.
- nadam 14y ago
  Ok, I accept this. I have experience in refactoring really bad code. Refactoring these always led to smaller code: yes sometimes some of the refactorings increased the code size, but there was enough redundancy because of the bad (or no) abstractions and design mistakes in the original code which compenstated for it. The bigger the system is, the more probable it is that you can make it better while decreasing the code size. Above 10.000 lines a bad code usually is not DRY enough so much, that it is very easy to decrease its size while increasing its modularity. Yes, code size is not a perfect indicator of quality. But reducing code size is a very central part of my design philosophy. When you very conciously refactor to smaller code size (using good design patterns) the code and the abstractions in your head can become incredibily clear. For example I write a software which deals a lot with rectangles. In the beginning my rectangles had four properties: left, right, top, bottom. After a while I've found out that my code gets more and more redundant; I have to find an abstraction which relies on the symmetries in the problems. So now my rectangle has this interface to get and set the 4 sides: void setSide(bool vert, bool isEnd, int value) int getSide(bool vert, bool isEnd) Not only my code size reduced dramatically, but because of this new abstraction I've understood the problem much better!

by nadam 14y ago

randomdata 14y ago

I think I understand where you are coming from, but DRY tends to, at least initially, increase the size of codebases and development time. The programmer who hacks something together that works now, but is a nightmare to maintain later will score better in your formula. As you say, it is an investment in the future, which implies that you are giving something up now for something more later.

mercurial 14y ago

> Small size reflects the quality of the code. Not always. Case in point: a week or two ago, I refactored some C# code. It was an installer generator, which was coded entirely in the controller. Yeh who want to add unit tests, abandon all hopes. So the code is now split into different pieces, according to responsibilities, with dependency injection, and I/O in its own layer. The result, in terms of lines of code, is a net increase. But according to your metric, I have decreased the quality of the code. I agree that generally speaking, less code is better than more code, but more code can mean reusable, more readable code.

nadam 14y ago
Ok, I accept this. I have experience in refactoring really bad code. Refactoring these always led to smaller code: yes sometimes some of the refactorings increased the code size, but there was enough redundancy because of the bad (or no) abstractions and design mistakes in the original code which compenstated for it. The bigger the system is, the more probable it is that you can make it better while decreasing the code size. Above 10.000 lines a bad code usually is not DRY enough so much, that it is very easy to decrease its size while increasing its modularity. Yes, code size is not a perfect indicator of quality. But reducing code size is a very central part of my design philosophy. When you very conciously refactor to smaller code size (using good design patterns) the code and the abstractions in your head can become incredibily clear. For example I write a software which deals a lot with rectangles. In the beginning my rectangles had four properties: left, right, top, bottom. After a while I've found out that my code gets more and more redundant; I have to find an abstraction which relies on the symmetries in the problems. So now my rectangle has this interface to get and set the 4 sides: void setSide(bool vert, bool isEnd, int value) int getSide(bool vert, bool isEnd) Not only my code size reduced dramatically, but because of this new abstraction I've understood the problem much better!