magic_lobster_party

  • 0 Posts
  • 32 Comments
Joined 1 month ago
cake
Cake day: August 15th, 2024

help-circle
  • What’s happening is that support from VC money is drying up. Tech companies have for a long time survived on the promise that they will eventually be much more profitable in the future. It doesn’t matter if it’s not profitable today. They will be in the future.

    Now we’re in a period where there’s more pressure on tech companies to be profitable today. That’s why they’re going for such anti consumer behaviors. They want to make more with less.

    I’m not sure if there’s a bubble bursting. It could just be a plateau.





  • I agree, and I count that as “key information that’s difficult to understand from the code”.

    IMO, comments should be used to provide value to the code. If they’re used too much, then readers of the code will more likely stop reading them altogether. They already got what they need from the code itself and the comments usually don’t add much value.

    If they’re sparse, then that’s a good indication they’re important and shouldn’t be missed.


  • I think comments are good as a last resort when it’s difficult to communicate the intention of the code with other means.

    If I find code that’s hard to understand, I’ll first try to find better variable or function names. Often this is enough.

    If it’s still too difficult to understand, I try to restructure the code to better communicate the flow of the code.

    If that doesn’t help (or is too difficult), then I might add a comment explaining key information that’s difficult to understand from the code.



  • In your example, the declaration of ArrayList look like:

    public class ArrayList extends AbstractList implements List {
    }
    

    The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.

    Compare it with my solution:

    public class ArrayList implements List {
        private AbstractList = new AbstractList();
    }
    

    Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.