On (2013年09月10日 00:08), Scott Johnson wrote: > > Thus Spoke ishikawa: >> >> I wonder if trying to re-indent legacy code according to the current style >> is a good idea or not. (It is a little irritating to modify a part of legacy >> code and find my editor trying to follow the current style while the rest of >> the file is in different style.) > I'd recommend we not do this, as it will likely break hg blame. I've > worked for companies in the past that checked in formatting changes > alongside other, functional changes, and it ended (even in small > codebases) in a lot of chaos - mostly that it was a) difficult to review > those changes and b) difficult to track back which > bugs/tickets/developers changed which sets of code. > > If we were going to do this, though, we should have a separate bug for > formatting changes, and check in those changes in separate patches > (maybe even one per file whose formatting is to be changed). > > ~Scott
So you are suggesting something like step 1 - request for formatting a file indented in an arcane format, i.e., reformat it according to the currently adopted code. step 2 - then after the re-formating of the file is done, particular bug or something is fixed in the newly formatted code. I understand the merit of leaving the code as is since hg blame won't work nicely with such file-wide format change as in step-1. (Or maybe we can teach hg blame to ignore such change, etc. but maybe too much work: the idea would be to mark formatting change with a particular string [maybe tag name] and let hg blame to ignore such tag to look for a previous patch that touched each line. Hmm. Maybe too much work indeed) OTOH, code in a strange indentation is hard to touch: during linux development around 2.1.1xx, Alan Cox got tired of the spaghetti code of SCSI driver subsystem and introduced a revision: that revision consisted only of sweeping reformatting of scsi subsystem files. No change except for re-formatting. It was felt the code could not be improved upon any more without such re-formatting. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
