I have replied again on Abhinaba's blog.
You said "I have time again seen that people point to intellisense and other editor features to justify or nullify arguments. But a editor feature can never justify design decisions. Not everyone uses VS editor. Moreover a lot of people have build systems that do not use solutions and rely on make files (nmake) or "sources" "dirs" files (NTBuild). Since there is no sln/proj files for the VS editor to use, intellisense do not work and users open CS files individually to edit. This is not a corner case situation and some teams even in MS uses this approach.". You're right, intellisense can't justify having lengthened/shortend etc Naming conventions, but neither can its use or lack of be used to justify the reverse [I think that makes sense]. I understand that you want to be as verbose as you can in as smaller an area, but I still think verbosity wins the day. Again for your second class, you shouldn't really be ripping the enums out and using them elsewhere [this could cause unintended consequences, at least having to change the class declaration makes it explicit that you know are changing all the enum refeneces], they should be referenced in the context that they are to be used in, and thus I belive having them in the class where it is initially related is the better choice. Obviously [and I might condraticy myself now] if you have many classes from the start that use them I agree with your point. But, if you have a file filter [specific to files] and a directory filter [specific to directories] I would keep them at class level named as filter and not at the namespace level named as FileFilter, DirectoryFilter.
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.
I love to learn about what you are building, and how I can help with Chrome or Web development in general, so if you want to chat with me directly, please feel free to book a consultation.
I'm trialing a newsletter, you can subscribe below (thank you!)
