Timeline for Code readability, conventions and should I let go
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 15, 2017 at 11:06 | comment | added | Jasper | @Stankar0x Interesting read (though a little dated). I'm not entirely sure that's what you're implying but under the "Bugs & style fixes" heading I never meant to say you shouldn't do that. I just meant to say that it may be better to do refactor-commit-refactor-commit-fix-commit, instead of refactor-refactor-fix-commit. I know I'm a bit on the extreme side when it comes to separating different things in different commits, but what I was saying is that if the bugfix was a couple of lines below the refactoring, it might have helped de-escalate the issue somewhat if they were separate commits. | |
| Nov 14, 2017 at 23:12 | comment | added | Stankar0x | [..] Here some references for those of you interested in this: link or his book: Refactoring Improving the Design of Existing Code. | |
| Nov 14, 2017 at 23:11 | comment | added | Stankar0x | I appreciate breaking down the problem as you did. I usually use a technique by Martin Fowler and refactor the code as I go along to make better sense to me or simplify it. So the style changes and bug fixes as well as tough code are all addressed by it. This is great when you have unit tests to back your assumptions. But also works when you do manual test while chasing bugs. Also when original programmers are unavailable, or when people are busy and don’t want or have time to discuss details with you.[..] | |
| Nov 14, 2017 at 17:46 | comment | added | James Snell | +1 for the Hobbyist code - many older coders come from that Hobbyist/RockStar school of "it's only other people that make bugs" and it takes a good deal of self-reflection and experience to realise why we all need the other aspects of software engineering like unit testing and readability. | |
| Nov 13, 2017 at 13:54 | history | answered | Jasper | CC BY-SA 3.0 |