Tag Info

Hot answers tagged

105

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


46

It's important to highlight positives as well as negatives. I know if I were reviewing the refactor of a particular hellish subsystem into something neat and clean, I'd probably buy the programmer a pizza for his efforts. If you're using reviews as training, it's doubly important - highlighting a good piece of code will be helpful for the junior programmers ...


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


40

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


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


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

Don't let it stop you, but don't build it for yourself either. There are very difficult and extreme restrictions on PCI compliance, which is the technical hoop you have to jump through to store credit card information. Do yourself a big favor and use a service like Authorize.net or Stripe that lets you store all of that sensitive data on their servers and ...


15

The way I understand it, a story-point is an estimate of relative effort, not man-hours. The effort required of a story isn't going to change just because a pair is working on it, so it doesn't make sense for the story points to change... Also, velocity is derived from the history of what got done in the previous sprint(s). If you pair on some stories and ...


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


13

Screenshots are an important aspect of the user guidance. However, they also need to be accompanied by clear and precise instructions. For example, having a screenshot showing the screen, a red arrow pointing to a button and the text reading 'Now that you have entered the filename, Click the Next button.' is much clearer than either the text or 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 ...


13

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


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

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


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


11

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


10

What you are looking for is profiling: In software engineering, profiling ("program profiling", "software profiling") is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or frequency and duration of function calls. The most common use of profiling ...


10

This may be a somewhat trivial advice, but try not to create attributes outside of __init__ method (especially not outside the class's methods), unless you really need to. pylint catches this, among many other things. Of course, there is still a possibility of reassigning an existing attribute to something else entirely, but at least you will have a single ...


10

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


9

In an ideal world, merge conflicts never happen. There are certain scenarios where merge conflicts are more common... So my advice to you would be avoid these scenarios. And here they are. Tightly coupled concerns Let's say you have a front-end engineer and a back-end engineer. And you run into conflicts. This is usually because your code is not ...


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


8

Obviously, firing them or reporting them to management is an option; whether or not it would be my first choice as an option would depend on whether or not they're also a good developer. It seems wrong-headed to send a very smart person packing just because they don't follow the process. Especially if you don't fully understand why they don't follow the ...


8

To put bug analysis in there is a good practice, for the reasons you mentioned (just avoid being overly verbose). This way, people reading it (including your future self) would know how much tricky the issue was and how much effort went in analysis and findings. Also, this way simplifies maintenance in the case when further changes are required related to ...


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


7

I document their activities, give them multiple written warnings, work with HR to create and implement an improvement plan, then I fire them. edit Since you're not the manager, the best you can do is document what you see (stick to facts) and forward to your manager once in a while. If any of your peers complain to you about this person, encourage them to ...


7

TL;DR Is it a good idea to use a kitchen-sink server for various services? There's no universally-correct answer to this question. It is fundamentally a business decision based on the budget you have and the problems you are trying to solve for. Arguments for Separating Services There are many reasons for separating services, but two of the biggest ...



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