Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sometimes, as an effort to read someone else's code, I'll actually refactor and reformat it in an effort to understand it better.


Refactoring is almost always good (almost the key word.) Reformatting, unless the code follows no style what-so-ever, is bad.


Just to clarify, I don't commit the reformatted code. It's just a temporary change to make it easier for me to read. :)


Really? Reformatting will solve the "bracket should be on a new line" problem, anyway.


Promiscuous reformatting causes large, unreadable deltas for every commit to the version control system.


So 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.


Exactly why I consider it a Good Idea to make commits that are either style or substance, but not mix both.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: