Tag Info

Hot answers tagged

300

But is it uncommon for developers to keep a personal copy of the code they wrote (for future reference)? I don't know how common it is, but common or not, it's still a bad idea. Programmers often operate in the mindset that solving the same problem twice is a waste of time. We try to design our code to be reusable (sometimes). We build libraries of ...


245

The biggest problem with this code is that you duplicated those 6 lines. Once you eliminate that duplication, that comment is useless. If you create a boutiqueDao.mergeOrPersist method you can rewrite this as: if (boutique == null) { boutique = new Boutique(); boutique.setSelected(false); } boutique.setSite(site); ...


157

I always keep a copy of the code I write and take it between jobs. Subsequent employers never get to see/run the code, but I use it as a reference at home: 'Ah yes, didn't I do something similar to that on Project X?'. Is this legal? Depends on jurisdiction and circumstances, but it is fairly common. Morally, I have no problem with it, providing you aren't ...


151

This is an absolutely horrifying idea. It does not make clear what the intent is. Did the developer comment out the line by mistake? To test something? What's going on?! Aside from the fact that I see 6 lines that are absolutely equal in both cases. Rather, you should prevent this code duplication. Then it will be clearer that in one case you additionally ...


149

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.


125

If you don't trust other developers, don't hire them. Working with people you don't trust is synonymous of failure. Technically, there is nothing you can do. You can force the developers you don't trust to work in a closed room on a machine which is not connected to the internet and doesn't have USB ports and search every developer each time he leaves the ...


110

No, it's a terrible idea. Based on that piece of code the following thoughts come up to my mind: This line is commented out because the developer was debugging it and forgot restore the line to its former state This line is commented out because it once was part of the business logic, but it is no longer the case This line is commented out because it ...


104

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


100

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


98

I commit code several times a day. Whenever I reach a point where the code is complete enough to compile and doesn't break other things, it goes in. You should look at breaking up your work so you can safely check-in a few times a day. The rationales for this are two: Any work that is not checked in may be lost - your computer may have a catastrophic ...


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


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

Most of the answers focus on how to refactor this one specific case, but let me offer a general answer to why commented out code is usually bad: First, commented out code isn't compiled. This is obvious, but it means that: The code might not even work. When the comment's dependencies change it will not obviously break. Commented code is very much ...


71

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


68

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


66

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


63

The problem I see is that the knowledge of setting up and configuring the virtual machine is not in-house, and if configuration is non-trivial then you'll be relying on the other company when the software needs to be configured for different versions of the OS/libraries/hardware/whatever. Accepting the VM is fine to get up and running faster, but I'd insist ...


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

That has got to be the dumbest bit of dumb management I've ever heard of, if they really mean 'checked into the shared trunk.' Reasonable solutions: Do work in task branches, and indeed check into those early and often. Run backups on the developer machines. Keep development trees on a shared file system and run backups on that.


54

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


51

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


51

"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

This is a very bad idea. That code doesn't belong to you (legally speaking) and having possession of it can get you into a lot of trouble. This becomes even more true when you move to a new job and still keep that source code around. Even worse if it's a competitor. Your company would not be happy if you had access to their source code when you don't work ...


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


49

I would just like to add to CodesInChaos's answer, by pointing out that you can refactor it further into small methods. Sharing common functionality by composition avoids the conditionals: function fill(boutique) { boutique.setSite(site); boutique.setUrlLogo(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getLogo()); ...



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