Tag Info

Hot answers tagged

150

One thing I have gotten in the habit of doing is always looking at the diffs of every file I'm about to check in, right before I check them in.


127

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


103

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


101

I've attempted to answer my own question here, but this is incorporating the heatmap idea from @jimp and also the 'make it more XML-ish' idea from @Andrea: Hopefully, the colors in the heat map along with the angular lines help draw the eye between the start and end tags; removing the horizontal line separators improves the 'flow' from start to end. As ...


86

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


84

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


75

It's an awful idea. It may be quicker in the short term, but it encourages badly documented hard-to-understand code as only the coder who wrote it is responsible for maintaining it. When someone leaves the company or goes on holiday the whole plan becomes mucked up. It also makes it very hard to allocate workloads; what happens when two urgent bugs come up ...


75

I think most answers missed the point here. You're adding multiple lines after method scopes, right? Well that's simply not a common convention. And because it's not a common convention, it's annoying to keep noticing it while reading code. So to be less annoyed: stick to one convention. Even if that's what your teammates want and you don't. Otherwise, ...


75

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


73

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


69

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


68

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


64

Deliberately overestimate the time needed for your next features. Use that extra time to clean up. You'll never be able to justify maintenance, and the client needs it regardless, so give them the bitter medicine (slightly increased costs for the next features) so they can get better.


63

You should never check-in commented-out code. If you have code that needs commenting out before check-ins, you are doing it wrong. As for rules: Get latest Fix merge conflicts Build 3.1 Fix build errors Run tests 4.1 Fix broken tests Go to 1 (until there is nothing new to get) Only check in when all steps are complete. See check-in dance. Other ...


59

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


56

Doesn't it mean it's rare to have things right right away? Exceedingly rare. In fact, if things run 'right' the first time, I normally assume that something is drastically wrong. Does it mean that the people demanding correctness right off the bat are unreasonable? Completely and utterly. And now, what is the way to avoid making mistakes now? ...


55

what I've always done is the following: Open multiple copies of my editor (Visual Studio/Eclipse/Whatever) and then debug and do line breaks step through the code. Find out the flow of the code, stack trace through to see where the key points are and go from there. I can look at method after method - but it's nice if I can click on something and then see ...


52

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


52

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


49

Partially. Code that uses Big English Words can be partially self-documenting in that the names for all the functions and variables can tell you what it is doing. But it probably won't tell you why. Compare: a->b; # what is b doing? what is the a object? carEngine->startIgnition; # much more clear what objects are involved But you still don't ...


49

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


47

One thing comes to mind: If you're the only administrator / root user of some system(s) that other people rely on, somehow sending the credentials to a trusted follower would be a good idea.


47

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


45

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


44

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


42

While experienced programmers make fewer errors than beginners, all programmers make mistakes. I've heard it said that since debugging is the process of removing bugs from the code, then writing the code in the first place should be called bugging, because it is the process in which bugs are added. As a beginner, you're writing small programs now and making ...


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