• 0 Posts
  • 155 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2023

help-circle
  • I usually use whatever the formatter does by default. Most are reasonable by default, and I might prefer things a different way personally, but I find that my job is easier when everyone else’s code is checked by CI to conform to the formatter’s style rather than being an unreadable mess of random newlines and weird mismatched indentation.

    The guideline that I follow is that if a tool doesn’t enforce a rule before the code can be merged, then it’s not a rule. Everyone, myself included (if I’m being particularly pressured on a feature), will overlook it at some point, whether intentional or not.

    For early returns, I think most reasonably configurable formatters support optional braces in those cases. This of course is assuming that’s a thing in your language, since many don’t have a concept of one-line unbraced returns (Python doesn’t use braces, Rust always expects them, etc). For consistency and just to have a rule, I usually just brace them because I know everyone will if it’s enforced rather than it varying person-to-person.









  • For tool configs? I’m not really sure I follow. All my source code for the project goes in src/ or some other subdirectory, and the project root is a bunch of configs, a source directory, maybe some scripts, etc. It’s never really bothered me.

    What has bothered me is __pycache__ directories. Whoever decided to litter those in every source directory all over the place… let’s just say I hope they learned to never do that again. I deal with enough trying to get Python to work at all (with the absolute hell it is to get imports working correctly, the random, but admittedly mostly documented, BS gotchas littered all over the standard library, packages with poor docs, no types, and every function worth calling taking **kwargs, etc). Seeing my code littered with these directories isn’t something I really want to deal with as well.

    A standard for build output might make sense to me. Maybe just throw cache stuff in .cache and build output to .build (with intermediate artifacts in there as well potentially). For configs, I wouldn’t really complain about it all going in .config, but it also doesn’t matter much to me, and sometimes you end up having nested configs anyway in nested project dirs (thinking of eslint configs, gitignores, etc).


  • the highest possible value for a product

    How do you calculate this?

    the amount of people who has the product - the amount of people who want the product

    As demand increases, the value increases, but at some point when demand exceeds supply (which is common), the opposite happens: the magnitude of the value starts to decrease (though that value is now negative).

    For example, two sellers sell a product, and four people want it. Let maximum value be v_m. Value is calculated to be v_m / (2 - 4) = -v_m / 2. If two more people want it suddenly (so 6 now), it becomes v_m / (2 - 6) = -v_m / 4, which has a lower magnitude despite the higher demand and static supply. This is contrary to how supply and demand actually work, where value generally increases as demand increases (if supply remains static).

    Maybe value means something differently to me than it does to you though. Ideally supply would always equal demand (which makes your denominator 0, breaking the equation entirely since that would be undefined), but that would be really difficult to control.





  • To me, it seems like this article is overemphasizing code duplication as problematic. If multiple types of searches use some of the same fields, it’s okay to just copy them to each search type that uses them. This also allows each search type to be independently updated later on to add additional fields or deprecate existing fields without affecting other search types.

    Fields that should always exist together should probably be moved to a struct containing those fields, if there’s some concept that encapsulates them. Paging fields, for example, that exist only on two of three variants can just live in their own struct, and those two variants can have fields of that type.

    Code duplication is only really problematic when all duplicates need to be updated together every time. That does not seem to be the case here.






  • The distribution is super important here too. Hashing any value to zero (or h(x) = 0) is valid, but a terrible distribution. The challenge is getting real-world values hashed in a mostly uniform distribution to avoid collisions where possible.

    Still, the contents of the article are useful even outside of hashing. It should just disclaim that the width of the output isn’t the only thing important in a hash function.