Tag Info

Hot answers tagged

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


47

To answer, you have to ask yourself how you expect to use the results of these commits in the future. The most common reasons are: To see what release a bug was introduced. To see why a certain line of code is present. To merge into another branch. To be able to check out a previous version for troubleshooting an issue a customer or tester is seeing in ...


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


39

I think whatever you do, try to avoid checking in code that you know won't compile. If you think your third option is feasible, that might be a good way to do it, as long as you can ensure that your sequence of commits won't create an uncompilable system. Otherwise, just do the one big commit. It's ugly, but it's simple, quick, and gets it done. Going ...


35

This is a conversation you should be having together, discussing the requirements and pros and cons of different formats. If one side or the other is dictating what happens, you're going to end up with bad software and an unhappy team.


18

A couple of things. Don't assume that your seniors don't know what they're doing. They may have very good reasons why they made the decisions that they did; ask them why (in a non-argumentative way). Code that is already written, backed by unit tests, and declared functionally complete by your superiors can be safely ignored. That's what you should do ...


16

The most important reason to make frequent, small, and meaningful commits is to aid understanding of the history of the code. In particular, it's very difficult to understand how code has changed if it's difficult to generate understandable diffs. Option 1 obfuscates the history of changes you've made, but otherwise it won't cause any problems. Option 2 ...


15

It is an altogether horrible practice. It adds effort in order to achieve an effect that is pure duplication; in other words, the only thing that it adds over just using commit logs is the possibility of creating inconsistency. Your source files become cluttered with unlimited amounts of stuff that you never look at. The only upside I can discern at all is ...


15

It is typical to have 2 week sprints. For me, the first sprint or 2 will likely have less "visible" features than later sprints for this exact reason (for some tenuous description of "less"). That being said, it certainly should not take you 2 weeks to build your entire scaffold and have nothing in the UI visible to show for it. Maybe you do not flesh ...


15

It's worth noting that, while the Python documentation provides a use case (and probably the canonical one) for this exception, it doesn't specifically exclude its use in other scenarios. I would consider it appropriate to raise a NotImplementedError exception if you haven't overridden a method in a base class yet (to satisfy the "interface"). A cursory ...


14

Would this be considered as bad, cowboy coding, anti-pattern. Short answer: no. Doing "agile" correctly does not mean "no planning", it does mean not to overanalyse things. one of the major reasons why Agile is used is because clients often change the requirements. That's an oversimplifying statement. "Changing requirements" is also about how the ...


13

The Agile Manifesto suggests that Working Software is more valuable than comprehensive documentation, and the Scrum framework takes this notion to suggest that delivering tested, working software with business value to be a requirement every sprint. Why? Well, among other things, designers and developers often fall victim to spending lots of time on YNNI ...


12

Although the only reasonable answer is to never break the trunk, some times it is not possible. For example, svn can break commit if you commit too much (maybe an option, or a feature, I am not sure). In such special cases, just check in in pieces. Since you are a single programmer it is not going to disturb anyone. Therefore, I would go for option 1. If ...


12

@RobertHarvey's comment is dead right: Process will not produce bug-free software, but good process can at least reduce the recurrence of classes of bugs. Sounds like you're attempting to accomplish the latter, so I will make my suggestion of where I think your mistake came in: You failed to account for all the details of your production environment in your ...


12

I recommend the following guidelines: Involve the junior developer in your design meetings and solicit his input. This will get him thinking about the big picture, even if he is not ready to do the high-level design himself. Try to isolate and clearly define a module of the application to assign to the junior developer. Describe in writing what the ...


11

It is, IMHO, a very bad idea. After revision number 100, you will have 90% comments and 10% code. I would not consider that as clean and readable. The only point in this I see is when you have to interchange your code between SCCs and, for whatever reason, you cannot transfer the history between the two systems (but even when you save the history comments ...


11

No. That's what people did before they used a version control system (i.e. when source code was just backups in zipfiles).


10

The advertised cycle of TDD is write tests until they fail then hack at the code until they pass again and then refactor while keeping all test succeeding. When the spec changes you will need to remove the old tests that would verify a violation of the new spec and write new tests that will verify the new spec.


9

Lets compare two jobs: Job A You develop low-level driver in C. If you don't know what a segfault is, then you are gonna have a really hard time doing your job and you risk making an awful lot of bad decisions that will create a very hard to find bug. If I was a recruiter, I would screen you immediately in interview and wouldn't even hire you if you ...


9

They are not following MINIMUM coding standards. If it's not your job to police the coding of others, then don't do it. It's a classic way for juniors to make a bad name for themselves. See this question for a similar discussion: How do I tell a senior programmer that I disagree with him Related: A blog post I wrote about disagreeing, and part of ...


9

Throw-away prototyping Throw-away prototyping is about creating, as fast as possible, a part of the future application to either ensure a feature is technically feasible or to show the feature to stakeholders or potential users in order to gather feedback from them. Since the source code of this prototype is not reused later when developing the application ...


8

What gets delivered to the client in these first iterations? What has highest business value for the user. For example, if the applications has complex business rules, the first iteration(s) will only contain those business rules encoded in the form of code. Customer should be satisfied as long as you have code for those business rules. (The problem of ...


8

I see that everyone is opposed to the idea and gave a historical reason (pre source control era) of why people were doing it. However, in my current company, database developers are following this practice and they additionally tag the bug number around the piece of code. I sometimes find this helpful when you see a bug in the code and you can instantly ...


8

Put simply: Don't boil the ocean. In other words, break off little, manageable chunks instead of trying to do the entire thing at once. In one branch. Without regular checkins. I've always liked this article at Joel on Software. It gives very good concrete examples about the kind of small changes that can be made against a code base to make it cleaner ...


8

Don't ask for pseudocode. If your superiors thought you needed that, they would have provided it already. Here's what you should do instead: Make your requirements testable If it's not testable, it's not a requirement; it's a feature or wish. More specifically, each individual requirement should be SMART: Specific Measurable Assignable Realistic ...


8

You most definetly should contribute to how the format and structure of the JSON should look like. I see it more than often that the front-end engineers, the API consumers, is the ones knowing how the data-structure should be. You are the one going to use the data, format it, loop through it and work with it. You should have an opinion on how you want it ...


7

One of the points in the Joel test is Do you have a bug database? Such information might be kept in a bug database if you think they're important, but they would only be noise in comments.


7

V-model is an extension of Waterfall model, so don't expect it to be hugely different. Basically, you follow V-model from left to right, just like in Waterfall model. In Waterfall, you do requirements, design, implementation, verification and finally maintenance. In the same way, in V-model, you do requirements, design, implementation, verification and ...


7

Try to break it into smaller commits that likely won't compile, as files have multiple fixes, changes, additional method names, etc. When I've found myself in similar situation I used following technique: Add only the code that is relevant to particular feature: git add --patch Stash all other changes: git stash save --keep-index Run tests/try ...


6

I think you have two problems here. First, why should you purely rely on the diff when most systems allow you to enter revision comments? Like good code comments, you discover why the change was made and not just the change itself. Second, if you have this capability, make it a good practice to put all of them in the same place. There isn't any need to look ...



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