332
This is an optimization problem
A good engineer understands that an optimization problem is meaningless without a target. You can't just optimize, you have to optimize for something. For example, your compiler options include optimizing for speed and optimizing for code size; these are sometimes opposite goals.
I like to tell my wife that my desk is ...
224
It seems you are refactoring "just in case", without knowing exactly which parts of the codebase in detail will be changed when the new feature development will take place. Otherwise, you would know if there is a real need to refactor the brittle modules, or if you can leave them as they are.
To say this straight: I think this is a doomed refactoring ...
143
Using multiple files always requires additional administrative overhead. One has to setup a build script and/or makefile with separated compiling and linking stages, make sure the dependencies between the different files are managed correctly, write a "zip" script for easier distribution of the source code by email or download, and so on. Modern IDEs today ...
142
Yes, you should refactor the code before you add the other features.
The trouble with comments like these is that they depend on particular circumstances of the environment in which the code base is running. The timeout programmed at a specific point may have been truly necessary when it was programmed.
But there are any number of things that might change ...
136
This is one of the situations where you are looking for a technical solution to a social problem.
A social problem should require a social solution, which, in this case, takes two complementary forms and an additional organizational solution which may help:
Trust. If you don't trust developers, don't hire them. Working with people you don't trust is ...
108
The first rule of any professional software engineer is to write code that is comprehensible. The second example looks like an optimized example for an older, non-optimizing compiler or just someone who happens to want to express themselves with bitwise operators. It's pretty clear what's going on if we are familiar with bitwise operations but unless you're ...
107
I've seen this done before, both manually by authors and automatically by scripts and triggers integrated with version control systems to add author, check-in comment, and date information to the file.
I think both methods are pretty terrible for two primary reasons. First, it adds clutter and noise to the file, especially as these comments age and become ...
87
Can my company give IP rights away for an application I wrote off hours to another startup? [closed]
IANAL. Contract does matter here. That's all I can say on that and I won't repeat the advice everyone else has given. The company may already own it and you have no say in the matter. Even a lawyer would tell you to hire a lawyer if you decide to simply say "No". So if that's your choice, hire a lawyer.
I read and re-read this question until I figured ...
85
There are several questions that you raise.
1) Is this a clear sign that the coder is not cut out for professional programming?
No. Developers often go through stages where they learn about an idea and want to apply it. Do they always apply these ideas efficiently and/or effectively. No. Mistakes are made, and it is part of the learning process. If ...
81
Because C isn't good at modularization. It gets messy (header files and #includes, extern functions, link-time errors, etc) and the more modules you bring in, the trickier it gets.
More modern languages have better modularization capabilities in part because they learned from C's mistakes, and they make it easier to break down your codebase into smaller, ...
78
Selling the source code for an app is very much like selling a business.
The standard formula is price = revenue * 3 + assets.
The multiplication of 3 is a factor of supply and demand. The more buyers a business has the higher the multiplier. When we hear about a business being purchased by ABC Corp in the news, it's often for a large figure. Those ...
77
Not really, no. There are a couple of reasons why:
Your version control system (VCS) stores this metadata already. E.g. each commit in git has a field for the name who made the commit. Competent version control systems allow you to see who made a change on a specific lines of code as well. That functionality is usually called blame which is a misnomer as, ...
77
V2.0 should have had what we used call a 'steady-state branch' (we used Perforce, not TFS) made for it once it was released. Any fixes for v2 would have been made to this branch and then propagated back into the v3 development branch while v3 features were also being worked on, i.e. a defect on v2 would result in a defect also on v3.
Having changes reside ...
70
The only thing I pluralize is collections.
foreach (var customer in customers)
{
// do something with customer
}
All of your examples are individual objects, so they are not pluralized. Yes, the names refer to objects that might have multiple instances, but all you need to know in the name is the object entity (i.e. customer).
So in all of your ...
70
Make them sign a non-disclosure agreement.
Only hire people you trust.
Compartmentalize your code base. Use of dependency injection so you can give them requirements that, when finished, resulting classes would fall right into place into the existing architecture, but they will not have acces to the "complete picture", only loose pieces. Only senior, trusted ...
66
Well, first of all, readability and maintability are often in the eye of the beholder.
What is readable to you may not be to your neighbour.
Maintainability often boils down to discoverability (how easily is a behaviour or concept discovered in the codebase) and discoverability is another subjective thing.
DDD
One of the ways DDD helps teams of ...
61
My question is: should I refactor the code when I encounter such warnings from the authors
No, or at least not yet. You imply that the level of automated testing is very low. You need tests before you can refactor with confidence.
for now we are no longer able to add any feature without breaking something else
Right now you need to focus on increasing ...
60
Use singular. The tool to turn screws with is called "screw driver" not "screws driver".
However, pluralize your method and property names accordingly, to indicate whether one value or a collection of them will be returned.
60
The hardest part of doing this sort of thing for the first time is really psychological - there is a very strong tendency to think of what it cost you in man hours, which is usually wildly inaccurate when done retrospectively and ignores the "I wasn't sitting at a desk but I was thinking about that algorithm all day..." and other overhead details, etc.
So ...
60
Because it's extra effort to create and maintain such a document, and too many people don't understand the associated benefits.
Many programmers aren't good technical writers (although many are); they rarely write documents strictly for human consumption, therefore they don't have practice and don't like doing it. Writing a code overview takes time that you ...
55
"Beauty is bought by judgement of the eye".
That said, I think most programmers will agree that beautiful code demonstrates a balance between clarity and transparency, elegance, efficiency and aesthetics.
Clarity and Transparency: Clarity is how easily a reader can deduce what the code does. Transparent code does what it seems to do. If code seems to do ...
50
Well there are multiple ways to deal with issues like that, generally covered by 'branching' tag, each with own set of benefits and downsides.
But approach chosen by your developers... gee I'll quote it verbally to make sure that I didn't misread...
code... will be kept on the developer's local machines until they are done...
...the way like above is ...
50
On early microcomputers editing was line based. You couldn't just move freely around in the source code and edit. You had a single line at the bottom of the screen where you could type commands and enter code. The rest of the screen was read-only code-listings and command output. If you wanted to edit say line 90 in the program you wrote "EDIT 90", and the ...
49
Can my company give IP rights away for an application I wrote off hours to another startup? [closed]
It depends on the your contract with Company A. Do they have any clauses in the contract regarding the works you write outside of work? Some do. If that's the case, I'm not sure what you can do. If not, you are still the owner of the code and you aren't obligated to give it up.
You could try to sell them the application source code. I agree that you ...
46
0-based indexing is for computers not humans
line numbers are for humans not computers
all humans are not programmers
1-based line numbers ease readability a tiny bit -- otherwise every time you saw an error message with a line number, you'd have to remember to decrement it by one to get to the actual line that caused the error -- and that impedes ...
45
I love the idea there might be a "clever" idea that "we" as developers would be baffled by. Given that every developer tool written was written by a developer and all that.
Your boss's biggest problem is naivety with a dash of paranoia. I'm being polite there. Really really polite.
If you really want a shopping list of things to keep your code proprietary,...
45
If you are thinking of BASIC dialects of the 8-bit home microcomputers of 80's, then those computers did not have text editors (unless you bought some word processor application). There was no way to have the entire BASIC program source code "open in an editor", like you would have when programming today. Programmer wouldn't even think about the program as a ...
43
I'm rather partial to Wikipedia's summary myself:
A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available.
A lot of what other people are ...
42
There is exactly one case where I would do this, namely as part of a warning for future programmers: "Don't call function foo() here directly; this has caused bug #1234, namely ...", and then a short description of the bug follows.
And if the code has changed in a way that there is no temptation to call foo() directly, remove that comment. It would only ...
Only top voted, non community-wiki answers of a minimum length are eligible
