3 ms·
Sometimes, as an effort to read someone else's code, I'll actually refactor and reformat it in an effort to understand it better.
by astine 17y ago
Sometimes, as an effort to read someone else's code, I'll actually refactor and reformat it in an effort to understand it better.
- wheaties 17y agoRefactoring is almost always good (almost the key word.) Reformatting, unless the code follows no style what-so-ever, is bad.
- araneae 17y agoReally? Reformatting will solve the "bracket should be on a new line" problem, anyway.
- Daniel_Newby 17y agoPromiscuous reformatting causes large, unreadable deltas for every commit to the version control system.
- Jach 17y agoSo keep it isolated in a separate branch? I do agree style wars are pointless. Personally, while I can and sometimes do have to use the style mentioned in point #3 of the blog post, I curse under my breath every time. (It should be: "\n} else {\n"! Not "\n}\nelse\n{\n"!) Saving myself that frustration can be useful. But for a better example, I'll sometimes come across code indented inconsistently with spaces and tabs, and need to reformat with :retab and == in vim. Separating complex code into chunks makes it easier to parse for me, adding comments, etc. etc. etc. Remember, this is to understand the code, not necessarily to make a bugfix. If I'm going to muck with someone else's code, I'll usually follow their style even if it's not mine. But I might first solve it in mine.
- jeffcoat 17y agoExactly why I consider it a Good Idea to make commits that are either style or substance, but not mix both.
- astine 17y agoJust to clarify, I don't commit the reformatted code. It's just a temporary change to make it easier for me to read. :)