| What's critical here is onboarding. Perhaps your code is "fine" from a different perspective, but because it doesn't fit in with existing conventions, styles, libraries, helper functions, ect, it needs to be refactored? For example, I work on a C# product. We have particular patterns for dependency injection, events, and multithreading. A newcomer from a different department once made a pull request that used static singletons and different event semantics. In this case, the newcomer gave a lot of pushback because we do things differently than the textbook examples of C# that they're used to. Our way meets the design needs of our product, thus it's the "right" way. The way that this developer made changes would be "correct" in a different product with different design needs and conventions. Normally, we avoid this by spending time with newcomers to explain the styles and patterns in our codebase. (In this case, this person from another department wasn't onboarded and just surprised us with a pull request.) We do document our coding style and design patterns; but it's important to point out that documentation is no replacement for common sense. If you've made it this far: 1: Professional programming isn't art or poetry; it's all about the finished product. Computer code is NOT a place for your self expression or creativity. (If that's important to you, go make some Wordpress themes or hack some other program to be skinned.) 2: It's important that professional code has consistent style and design patterns, otherwise it's extremely hard to read each time a module uses a different style. 2.5: Thus, the most important part of good style is trying to fit in with the existing style whenever possible. (IE, if you use tabs, but everyone else uses spaces, you need to switch to spaces.) 3: If this is a case of "growing pains," take the time to document your codebase's style, design patterns, ect. |