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


60

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


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


41

Lots of participants in the software development process are not developers, and need the ability to interact with documentation regardless. Should QA/Marketing use word and developers use something else completely? It would be inconsistent, it would add another tool into the maintenance chain and the IT portion of a company may have no idea what to do with ...


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


22

Short answer You should consider that it's a very risky and costly idea that may not give you as many benefits as you think it might. Long answer You should consider the following: C++ is a language that can be used at a very high level, that is cross platform (though that depends on how much you used the VC proprietary extensions) and for which many ...


19

Pure Git way .gitignore included file with private data Use a local branch, in which you replace TEMPLATE with DATA Use smudge/clean filters, in which (local) filter's script perform bidirectional replacement TEMPLATE <-> DATA Mercurial way MQ-patch(es) on top of dummy code, which replace TEMPLATE with DATA (changesets are public, patch is private) ...


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


17

Your situation is quite common and when I was developing things for non-technical clients it happened to me all the time. When those people hire you they most often don't know what they really want. They just know they want "something like that" or "something that can help me with this". Part of a job of a competent software developer is to help those ...


16

You could put all the private/protected keys as system environment variables. Your configuration file will look like this: private.key=#{systemEnvironment['PRIVATE_KEY']} This is how we handle those cases and nothing goes into code. It works very well combined with different property files and profiles. We use different property files for different ...


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

It sounds like your'e about to make a lot of really bad decisions. Highlight the development time is comparatively lesser in C# than C++. That sounds incredibly suspect. It's certainly not true if your team knows C++ but doesn't know C#, for instance. I feel there are many features in C# like Collections, Generics, and other libraries which can be ...


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


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

Yes, there are definitely situations where it makes sense to create some down and dirty "throwaway" code with the intent of tossing it after a couple years and starting over. Perhaps your company is trying to quickly prove out a new business model and want to get a sense of the market reaction to a "test product". Perhaps there is an untapped market and ...


11

Modern variations of vi, ksh etc are all standard on every linux distro you will come across. Be warned that now days when you type vi you get vim - very few people use true vi, but is is available if you do not want to use vim. ksh is close enough you will be right at home immediately. Modern C compilers might complain about a lot of you older C source ...


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

In this situation, code reviews would be a great way to spread Objective-C/iOS knowledge throughout the team, so that someone else can fix bugs when the iOS developer goes on a honeymoon/quits in a huff/gets hit by a bus/is moved to a higher priority project. Finding bugs is only half the value of code reviews. Spreading knowledge (about both the technology ...


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


9

The ability to reuse software does not prevent process improvement. If you think about the processes that go into building software - developing requirements, designing the system, implementing the system, deploying the system, managing requirements, managing configurations, verifying and validating work product, tracking changes, and a number of others ...



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