308

The premise of the question is, frankly, astounding. We suppose that there is a large change to fragile, complex code, and that there is simply not enough time to review it properly. This is the very last code you should be spending less time on reviewing! This question indicates that you have structural problems not only in your code itself, but in your ...


258

There are a few reasons. Nobody reads documentation. Nobody follows the documentation even if they do read it. Nobody updates the documentation even if they do read it and follow it. Writing a list of practices is much less effective than creating a culture. Coding standards are not about what people should do, but are about what they actually do. When ...


245

Even though I use Git on the command line – I have to agree with your colleagues. It is not sensible to squash large changes into a single commit. You are losing history that way, not just making it less visible. The point of source control is to track the history of all changes. When did what change why? To that end, every commit contains pointers to ...


178

Good answers so far, but they don't cover all the bases. In my experience, many people fresh out of college have fantastic theoretical knowledge - far better than me or many other seniors with decades building software for a living. BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory ...


164

You have to be pragmatic. If the error is unlikely to be triggered in the real world and the cost to fix is high, I doubt many people would consider it a good use of resources to fix. On that basis I'd say leave it but ensure the hack is documented for you or your successor in a few months (see last paragraph). That said, you should use this issue as a "...


143

As far as I'm concerned, your source control repo is part of the basic project setup, so I commit right after I generate my empty project.


138

If it is truly a 1 in 10^55 event, there would be no need to code for it. That would imply that if you did the operation 1 million times a second, you'd get one bug every 3 * 10^41 years which is, roughly, 10^31 times the age of the universe. If your application has an error only once in every trillion trillion billion ages of the universe, that's probably ...


137

I am a part-time programming teacher at a local community college. The first course that is taught at this college is Java Programming and Algorithms. This is a course that starts with basic loops and conditions, and ends with inheritance, polymorphism and an introduction to collections. All in one semester, to students who have never written a line of ...


132

Don't put your secret information in your code. Put it into a configuration file which is read by your code at startup. Configuration files shouldn't be put on version control, unless they are the "factory defaults", and then they shouldn't have any private information. See also the question Version control and personal configuration file for how to do this ...


129

An iterative process will achieve this nicely, without detailed specifications. Simply create a sketchy prototype, ask for feedback from the customer, make changes based on the feedback, and repeat this process until the application is completed. Whether the customer is patient enough to do it this way is a different question. Some clients and developers ...


115

There's another interpretation. I don't believe it is what Uncle Bob meant, but it is worth considering. Don't capture coding standards in a document. Capture it in code, by having an automated process which verifies the standards are being met. Don't rely on people referencing a document, but at the same time, don't rely on people interpreting the code ...


114

Captain Obvious to the Rescue! I'll be Captain Obvious here and say that there's some middle ground to be found. You do want to build for the future and avoid locking yourself into a technological choice or a bad design. But you don't want to spend 3 months designing something that should be simple, or adding extension points for a quick and dirty app that ...


112

Automation. When you are developing, only in the most simple projects will the default "build" button do everything you need it to do; you may need to create WS out of APIs, generate docs, link with external resources, deploy the changes to a server, etc. Some IDEs allow you to customize the build process by adding extra steps or builders, but that only ...


110

I'll take a crack at this from a managerial standpoint, but keep in mind that I'm aware I don't have all of the details. I'll summarize what I see: Mid-level developer, we'll call him "Scott", recommends a rewrite of legacy code into SSIS to improve the performance of important process ProcessA. ProcessA is currently behaving in a functioning state with no ...


110

I like Amon's answer, but I felt one small part needed a lot more emphasis: You can easily simplify history while viewing logs to meet your needs, but others cannot add history while viewing logs to meet their needs. This is why keeping the history as it occurred is preferable. Here's an example from one of our repositories. We use a pull-request model, ...


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


106

"The Mythical Man-Month" came out the year I started college and was, to use the current vernacular, UUUGE! :-) What you need to understand is the difference in how software was developed THEN vs. NOW. Back In The Day (tm) pretty much all coding was done on paper first, was then keypunched onto (you guessed it) punched cards, then was read in, compiled, ...


104

You should commit as soon as you have a sensible "unit" complete. What is a unit? It depends on what you're doing; if you're creating a Visual Studio project, for example, commit the solution right after its creation, even if it doesn't have anything in it. From there on, keep committing as often as possible, but still commit only completed "units" (e.g. ...


102

This is a symptom of a wider migration towards distributed version control systems. Some websites which traditionally hosted non distributed VCS (eg Codeplex & SourceForge) were a little slow in adding support for DVCS (eg Git or Mercurial). So, people who wanted to use DVCS for their project were forced to migrate their projects over to the providers ...


100

This is a very common experience Most people I interact with, and I myself as well, feel like this. From what I can tell one reason for this is that you learn more about the domain and the tools you use as you write your code, which leads you to recognize many opportunities for improvement after you've already written your program. The other reason is ...


99

One of the primary goal of a code review is to increase quality and deliver robust code. Robust, because 4 eyes usually spot more problems than 2. And the reviewer who has not written the additional code is more likely to challenge (potentially wrong) assumptions. Avoiding peer reviews would in your case only contribute to increase fragility of your code....


99

First of all, we have to fundamentally distinguish between Computer Science and Software Engineering. (And maybe to a lesser extent between Software Engineering and Programming or "Coding".) As one of my CS professors put it: if you need a keyboard, you are not doing CS. TDD is very much a Software Engineering practice. It doesn't really have much relation ...


97

So I don't waste much time on writing super clean code at that point because I never know how long something lasts. Not knowing how long something lasts should never be an excuse for sloppiness - quite the opposite. The cleanest code is IMHO the one which does not come into your way when you have to change something. So my recommendation is: always try to ...


97

I think it's a little disingenuous to say that good developers never have merge conflicts, but they can surely reduce the number of times it happens. It's also very important to remember that software development is a team activity. Actions of other members of the teams can also increase or decrease the likelihood of merge conflicts. First, it's important ...


91

You need a proper Quality Assurance (QA) process. In a professional software development team, you don't push from development right to production. You have at least three separate environments: development, staging and production. When you think that you got something working in your development environment, you push to staging first, where each commit is ...


88

There are some aspects of that concept that are sometimes implemented today, there are other aspects that are avoided. Keeping teams small is one of the basic features of Agile Methods, but is also practiced outside of Agile. Cross-functional teams are also a staple of Agile, but common outside of Agile as well. The role of the Program Clerk is largely ...


87

I use : initialize() terminate() I find it the more appropriate: it's hard to not see it in code, because it's both long words (I don't use init) it's correct english (AFAIK) in my head, terminate avoids ambiguity. It doesn't match begin (which matches end), start (which matches stop), create (which matches destroy), setup (which matches unset), load (...


78

Yesterday ...in alternative, if you're unable to time-travel... (maybe your car can't get to 88mph, or your flux capacitor just snapped) Now New projects should be committed on the bloody spot, it's crazy not to, and contemporary DVCS systems just removed every possibile excuse to avoid commits: git init . ; git add * ; git commit -m initial-commit now, ...


78

There was a similar bug in Windows 95 that caused computers to crash after 49.7 days. It was only noticed some years after release, since very few Win95 systems stayed up that long anyway. So there's one point: bugs may be rendered irrelevant by other, more important bugs. What you have to do is a risk assessment for the program as a whole and an impact ...


77

A few things stand out to me. The idea that management has that the team commits to a set of work is inconsistent with the latest versions of the Scrum Guide. The word "commit" or "commitment" is only used twice in the most recent (November 2017) version of the Scrum Guide - once when listing the Scrum Values and once to indicate that "people personally ...


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