Tag Info

New answers tagged

0

If this code is presented during code review, it seems you have little problem; just provide feedback that you are not clear what it does and ask for a unit test. If it's not during code review, then you might want to think not just about how to rectify the immediate issue, but look for a deeper solution in terms of process change. Any of the following ...


1

I would've preferred to post this as a comment alas I'm short on rep. In my world, if I can't directly trace a piece of a code to a documented requirement or derived requirement then I flag it for a team review which occurs every two weeks or as needed. // REVIEW: 05/19/2015 // Can't find the need for this code. Perhaps it's been orphaned? ...


11

Stay with me here. When I say the code "does nothing", I mean something like the following function The correct term for this type of source code is incomplete. You could say to another programmer "Upon reviewing your source code I found a function that is incomplete. Can you clarify its intent?" Incomplete work makes it's way into production products ...


1

I worry that this slowdown would reflect badly on me and my performance. If improving the code you find reflects badly on you, then you have a much bigger problem in your team than exactly how you raise the issues you find! OK, if it's not broken you don't have to fix it, but for genuine redundant code it's probably a good idea to simplify by removing ...


1

Ask the dev to walk you through the code in code-review session, and ask what his thought process was around it. See if he recognises the superfluous behaviour. If he doesn't, ask him specifically about it. Maybe a bit more roundabout, but not as confrontational.


79

The easiest way is to ask from a point of not understanding and ask their opinion. It's no good to say "your code sucks", it's quite another to say "erm, I saw this and I really can't understand what it's doing, or why it's doing it. What do you think?" or similar - you could say what your concern is and ask them to explain it to you, or ask them just if you ...


14

The purpose of all code is ultimately to affect the world outside the program in some way. Nobody cares about the content of memory cells or CPU registers; they only care about the printed page or the information displayed on a screen. If code doesn't input/output anything, and doesnt change the state of the program in any way that could eventually cause any ...


1

If nothing exits or is referenced outside of the scope of the system that the code represents, it has no use. You just have to draw a line around the entire system and challenge the obstinate dev to point out where it's actually crossed.


1

It largely depends on what fields you would want, as 17 of 26 indicated: TFS is highly customisable. The reason I would want to do this as opposed to use something like JIRA is that you get a single view of what your developers are working on, as opposed to having to aggregate two systems. TFS also has resource capacity planning, and if you're not showing ...


3

I would take one of two views, depending how confident I was that I was talking about the same thing as the original reporter: 1) Since the reporter is no longer available, deem that the bug in question means whatever it was you fixed. If it helps, attach test cases to make clear what failures you found. Describe in detail on the bug report what it was you ...


7

I read this as more a question about the practices around how to handle an unverified bug (using github's issue tracker) than anything else. To me, that is a rather straight forward answer based on other issue trackers I have used. Github doesn't force anyone to use any workflow and this makes it very flexible... and rather useless in its default ...


10

Your main question was already answered, but you also asked about documenting the process and that needs answering too. The solution I've seen in many projects is not to put it in the project's README.md, but in a special contribution README - a README file for contributors. This file describes everything you want the people contributing to your project to ...


44

This is a dilemma: you cannot close the issue as "fixed", because you don't actually know if it was fixed, or at least even if some issue was fixed, you don't actually know whether this was the issue the reporter was talking about. On the other hand, you don't want to leave an issue that might have been fixed open, especially if you won't ever be able to ...



Top 50 recent answers are included