Timeline for Code readability, conventions and should I let go
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 14, 2017 at 17:41 | comment | added | James Snell | @emory - the OP was trying to fix a bug. The code was poorly written and needed refactoring to follow and only then was the bug found to be elsewhere (a few lines below the refactored part). That's absolutely code I'd need to refactor just to follow it, and when confronted by the "senior" dev their attitude prompt an opportunity to remind them that I wouldn't have been fixing a bug if they hadn't left one there and wouldn't have had to refactor if it had met the corp standards. The only "out" I'd give them is if that section of the codebase predated those (which it may well do.) | |
| Nov 14, 2017 at 15:00 | comment | added | emory | @Mat'sMug why would you want to read the code other than (1) fixing a bug or (2) adding a new feature. if you are fixing a bug then you should start by writing that failing unit test. if you are adding a new feature, the lack of that feature is a failing unit test. if you are reading the code for fun, stop and do some real work. | |
| Nov 14, 2017 at 14:34 | comment | added | Mathieu Guindon | @emory no. unit tests cover whether the code does what it needs to do - not whether it's implemented in a readable way. And if your tests turn implementation details into specs, then your tests are casting the entire code base in cement. | |
| Nov 14, 2017 at 14:05 | comment | added | emory | @Mat'sMug you are unable to write a single failing unit test you but you still want to muck with the code. Either the code is perfect as is or you do not really understand it. Keep writing unit tests until you found a failing and then refactor. | |
| Nov 14, 2017 at 12:56 | comment | added | Mathieu Guindon | @emory the entire Code Review community disagrees with that statement. | |
| Nov 14, 2017 at 0:54 | comment | added | Stephan Branczyk | @emory, I disagree. | |
| Nov 13, 2017 at 21:04 | comment | added | emory | @akaioi I would go further. Do not touch the code unless it is necessary to fix a failing unit test. Do not fix what is not broken. | |
| Nov 13, 2017 at 10:18 | history | edited | Stephan Branczyk | CC BY-SA 3.0 |
deleted 2 characters in body
|
| Nov 13, 2017 at 6:24 | comment | added | akaioi | +20zillion for mentioning unit tests. ;D This will make any changes immensely safer to implement! | |
| Nov 13, 2017 at 2:38 | history | edited | Stephan Branczyk | CC BY-SA 3.0 |
added 10 characters in body
|
| Nov 13, 2017 at 2:33 | history | edited | Stephan Branczyk | CC BY-SA 3.0 |
added 285 characters in body
|
| Nov 13, 2017 at 2:27 | history | edited | Stephan Branczyk | CC BY-SA 3.0 |
added 285 characters in body
|
| Nov 13, 2017 at 2:17 | history | answered | Stephan Branczyk | CC BY-SA 3.0 |