Timeline for What to do when code submitted for code review appears to be too complicated?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 19, 2016 at 2:08 | comment | added | user541686 | Wow this advice really is SOLID! | |
| Dec 18, 2016 at 20:10 | comment | added | Eight-Bit Guru | Aside from ensuring all of my teams' builds go through SonarQube, I also tell them to assume that the next person to make changes to their code is a psychotic axe-collector who knows where they live... | |
| Dec 18, 2016 at 13:59 | comment | added | candied_orange | It is entirely to easy to write code that works but can't be read. The point of the code review is to tell you what the compiler wont: how well this code runs in a human mind. | |
| Dec 18, 2016 at 9:53 | comment | added | Christian Strempfer | This answer sounds good, but is unrealistic often. If you're heavily dependent on existing frameworks, you cannot refactor the complicated parts. | |
| Dec 18, 2016 at 8:30 | comment | added | Rocío García Luque | This is so important that I am going to print it. | |
| Dec 16, 2016 at 15:47 | comment | added | Kevin Fee | @CodyGray Obviously this is somewhat a matter of opinion, but in mine, Code Review is being used too often as a method for finding bugs when that's just a happy side effect. It's like using blood pressure medication to treat erectile dysfunction. Not what it's for, but it works so well! Code review is for ensuring that more people than just the author have viewed and understand the code. Nothing's worse than having just one author who knows the code, then they decide to leave. | |
| Dec 16, 2016 at 15:32 | comment | added | Cody Gray | I disagree that code review "isn't" for finding bugs. It often does find bugs, and that is a very powerful and useful aspect of code reviews. Better yet, it helps find ways to avoid bugs entirely in future code. The point is perhaps overstated, and should be that it's not exclusively to find bugs! | |
| Dec 16, 2016 at 11:30 | comment | added | Angew is no longer proud of SO | @SGR Doesn't really apply to neurons, though, which happen to matter the most here. | |
| Dec 16, 2016 at 11:08 | comment | added | SGR | @chrylis Especially if you consider that pretty much every cell in your body will have died and been replaced within 6 months, you're pretty much biologically a different person as well. | |
| Dec 16, 2016 at 4:21 | comment | added | Nelson | Put the code away for some time (long enough for him to not remember everything). Ask the original coder to review it. See if HE understands it. | |
| Dec 15, 2016 at 23:40 | comment | added | chrylis -cautiouslyoptimistic- | @DavidGrinberg For all practical purposes, "you in six months" is a completely different person. | |
| Dec 15, 2016 at 22:41 | comment | added | user223083 | good answer. it depends on the purpose of "code review". readability is one thing, structure another - but their very closely related. fwiw I'm working with some open source written by MAJOR corps, and it's almost unreadable because the var and fn names are so hair-brained. | |
| Dec 15, 2016 at 21:30 | comment | added | David says Reinstate Monica | This very much. Remember that its not just you and the writer who will be reading this code. It will also be some random intern in 10 years, so you want to make sure he has a chance of being able to understand whats going on. | |
| Dec 15, 2016 at 16:32 | history | answered | Kevin Fee | CC BY-SA 3.0 |