<p><pre><code> Over the years I have realized that some comments are
needed and useful. These days I add comments when there
is something particularly tricky, either with the
implementation, or in the domain.
</code></pre>
Ah, yes. Another convert. There are dozens of us. Dozens!!<p>Nothing makes me feel crazier than trying to get fellow engineers to comment their code. Code alone can only tell you the "what." If the "why" is not obvious, comment it.<p><pre><code> Unit testing private methods.
</code></pre>
I am always dismayed by engineers who vote a hard and unyielding "no" on this issue.<p>I guess ideally your private methods should not be tested directly. If you work at an ideal shop doing ideal things under ideal conditions, please let me know if you are hiring.<p>In all or most of these cases the tests for private code will hopefully be somewhat temporary; perhaps think of them as scaffolding used during construction or renovation.<p>- For example, perhaps you have a good reason to write the private methods first and you would like to make sure they are sound before proceeding.<p>- Perhaps you have a division of labor due to a time crunch and you are writing the private methods while somebody simultaneously writes the public methods.<p>- Perhaps you are encountering some thorny preexisting code with no test coverage and you would like to just make sure things work.<p>- Perhaps the public methods are undergoing a lot of flux and you would like to make sure the private methods do not suffer regressions during this flux<p>- Sometimes it's just <i>easier</i> to test private methods directly rather than indirectly via a public interface. Maybe this is a code smell, but also maybe you don't have time for a full refactor.
I’ve never understood why anyone would choose to debug by printing and logging if they have a good debugger available to them.<p>My day job is mostly PHP (yeah yeah, I know) and the general attitude towards Xdebug in the community seems to lie somewhere between apathy and active avoidance.<p>To me, a debugger is such an invaluable tool not only for identification of bugs but also for familiarising oneself with new code. The value of being able to not only trace execution from start to finish but also to <i>modify</i> state in a running program is immense, and gives me a small taste of what Lisp folks rave about.<p>Littering print statements everywhere feels like banging rocks together when there’s a perfectly good lighter in your pocket.
>> I used to think that the names of the classes, methods and variables should be enough to understand what the program does. No comments should be needed. Over the years I have realized that some comments are needed and useful.<p>Comments are needed where there is more to the code than just reading it. Where there is some external reason WHY. Where it is written in a specific way for non-obvious reasons. Where there are pitfalls and dangers in changing the code. Where this specific approach is the result of fixing some problem and if you change it then you might be reintroducing a problem.<p>There's lots of reasons to comment your code, but mostly I think code should be the documentation.<p>The fewer comments the better, because then developers who come later will see comments and thing "this must be important because there is a comment here". Too many comments dilutes the value of comments.<p>When it really matters I start my comment with a couple of lines like this:<p><pre><code> // LISTEN UP!!!
// LISTEN UP!!!
</code></pre>
I have to say, it seems strange that the author EVER thought that no comments should ever be needed - that seems like a strange and dogmatic conclusion to have come to.
I wish that my programming languages had a "public for testing only" scope. Despite the rigorous arguments of the Properly Factor Your Public API crew, I still find myself in real-world situations with functions that should not reasonably be used outside of the module, but that I still find valuable to cover with unit tests.
It would be interesting to know how long the author has been developing software.<p>For me, this is the kind of stuff I questioned in my first few years. After I productionalized a few real world systems for a business, the whole “dev street cred” thing lost it’s appeal. It wasn’t about some imaginary “dev purity” thing anymore, it was about being efficient and making sure I was contributing to the bottom line.
Overall a pretty good article, however I do feel like the author misses the mark on a couple points.<p>> Unit testing private methods.<p>As someone else pointed out this leads to accidental testing. I'm not a test zealot, I think 100% coverage is a fool's errand, and I think TDD is an abomination, but well-structured, well-thought-out tests can be a game changer when used appropriately. Testing things by accident has inevitably lead me to finishing some piece of work then spending half a day or more tracking down why some test failed inexplicably.<p>> Using an IDE.<p>I think a better point here is to get really good with whatever tool you use. If you know every incantation in vim you're going to be amazingly productive. If you know every keyboard shortcut in IntelliJ you'll be as effective, but probably not much more. The person who knows vim or emacs in and out will beat the person clicking around in an IDE every day of the week.<p>That being said some of it is spot on in my admittedly limited experience (only about 13 years or so, in a handful of industries, never FAANG-level scale). The point about commenting problem areas in the <i>domain</i> has really changed my approach to comments. I don't write any comments about what the code is doing unless it's a "here be dragons, don't change $X unless you're free the rest of the week" kind of warnings. But I comment extensively why the business or regulation requires A or B to happen instead of the more straightforward C.<p>The ChatGPT bit as well matches my experience. For well-defined things where it's hard for ChatGPT to make the answer up, and easy for you to verify if it does (or at least low-damage), it's worth the $20/mo IMO. I tried using it to learn CDK and while I'm not sure it saved me any time, it did save me from having to trawl through AWS documentation.
Unit testing private methods via public interfaces is accidental testing and leads to overly complex and brittle test code. The author’s first instincts were correct here.
IDEs are a deep topic but I don't hold such absolute.<p>For some languages using commercial IDEs is a very smart choice. Refactoring TypeScipt, for example, with Jetbrains IDE is a breeze, and I think it should be available in developers toolkit whatever their preference is.<p>For some, more dynamic/niche languages (Hello Elixir!), IDEs stand in a way because they take longer to set up and they still don’t produce results as good as glued together scripts and editor macros (side note: macros aren’t only for inserting text, one can pick text under cursor and search for a specific pattern using rg or even send refresh signal to a browser on the other screen).<p>There are also two other layers that I always mention as arguments against IDEs.<p>First is that IDEs change often and no matter how much you try your workflows are going to change. It’s hard to get high proficiency when things are changing and having new IDE feature replacing Your Way is a pain and a learning deterrent (thing that I experienced multiple times).<p>Second is something I call GPS Development. When I work with IDE I tend to not pay attention where am I and where I should be going because hopping navigation is super easy. And then when I am deprived of those tools I’m completely lost and not productive at all. With arguably dumber tools I can open shell and still navigate and edit with whatever editor I have and it still works well. Thing is that with my line of work stuff breaks often and IDEs rightfully decline to work on broken codebase.<p>My current stance is to use whatever you’re most comfortable with (on a unit by unit basis). Struggling with editor or IDE, even the coolest/smartest one, is going to interrupt your thinking process and cause performance hit much bigger than whatever gains it could ever produce.
> <i>Using an IDE [is great, in particular for navigating the codebase]</i><p>As a longtime and ongoing Emacs user... I have to agree.<p>Sure, Emacs Can Do It [tm?], but having to setup the appropriate tag system, and ensuring it's kept up-to-date with the codebase is a pain.<p>For example, our codebase is embedded C with #ifdefs depending on which target we're building from. This means that a naive, cscope(regex)-like search will get confused about which is the proper definition for the active target... when it even can find a definition (it's shocking how often it fails for no clear reason).<p>So I turned to RTags, which meant having to generate compile-commands.json, which... I'll stop here. Suffice to say setup wasn't trivial, and for some reason it eventually broke and I never bothered again.<p>Rinse and repeat for every other language.
Debugging by printf is useful in a bunch of places. Debugging via debugger is useful in a bunch of places. Why would I limit myself to only one? (Doesn't matter <i>which</i> one; why would I limit myself?)
I echo the comments on Emacs. Jetbrains tooling is just so /nice/.<p>You can get your Emacs to act like Jetbrains in a number of ways, but that can sometimes end up being quite complicated. I very much like the experience of opening any Jetbrains IDE and having this working relatively easily compared to Emacs.<p>All that being said, investing in Emacs gives you benefits you won't find anywhere else.<p>For example, I was able to make my Emacs find by reference and find by definition functionality work well and exactly the way I wanted it to.<p>I basically set it up to fall back on resources if the previous one didn't return anything. It went from Language Server Protocol -> CTags -> Regex with rg.<p>It was also cool to pick multiple sources and priority order them for suggestions. Mine, from highest to lowest priority, were: Language Server Protocol -> local buffer matches -> open buffer matches (or something like that, it's been a while since I touched my config).<p>This made it so that I'd get suggestions from my LSP for code, but if I were typing a comment and repeating a word I've used before then LSP would come up empty but Emacs would be auto-completing that word for me.
It seems to me that the underlying theme is "I was a bit stubborn and dogmatic, now I learned that the other side was not as bad as I pictured".
It's weird to see Emacs lumped in with VI in the editor wars rather than being thought of as an IDE. Emacs is the ultimate and original integrated development environment. The joke is that Emacs users have integrated everything into Emacs, so much so that Emacs is the OS.<p>That's one of the main reasons I picked up Emacs back in the day -- it provided a nice integration with gdb.
Decent insights but nothing earth shattering<p>The whole point is ignoring the dogmatism of our profession full of various shamans with magic formulas to solve everything from scrum to xp to tdd to rust to functional programming to ood etc.<p>Then it’s always the same shit, but it’s your fault because you didnt do this or that<p>It reminds me of something…
I’m always surprised this is controversial but: everything you write in a commit message should be evident from your code and its comments. Nobody should ever have to look at git history to understand a codebase.
With lsp, the gap between IDEs vs text editors is narrowing. While I still prefer Emacs, I’m pragmatic enough to jump on to whatever tool does a better job for a specific task. At times, that is Xcode.<p>Was also sceptical about ChatGPT and changed my mind like OP. I was less pragmatic on this one and brought ChatGPT over to Emacs <a href="https://github.com/xenodium/chatgpt-shell">https://github.com/xenodium/chatgpt-shell</a>. Pretty happy with the result so far.
With IntelliJ, spellchecker + linter + static analysis + duplicate code detection + etc = basic quality as opt out feature<p>VS Code and other setups make those opt in.<p>Meaning, when you see a bunch of typos and really poorly written code you know it is from one of the DIY setup people.<p>So then you have to move all those checks to the next stages like SCM hooks and CI.