Traps to Developers
qouteall.fun
Traps to Developers
1–10 of 113 posts
Re: Traps to Developers
#2That's a nice compendium of tips and useful information.
I wonder if anyone can learn from this. I feel like I only understood what I already knew, or at least was very close to knowing. That's the same thing that happens with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topics, but often very bad at teaching the same topics to an audience that doesn't know anything.
Re: Traps to Developers
#3A recent trap for me:
Regex semantics is subtly different across languages. E.g. a{,3} matches between 0 and 3 "a" characters in Python. In JavaScript it matches the literal string "a{,3}".
Re: Traps to Developers
#4That's a nice compendium of tips and useful information. I wonder if anyone can learn from this. I feel like I only understood what I already knew, or at least was very close to knowing. That's the same thing that happens with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topics, but often very bad at teaching the same topics to an audience…
> with teaching manuals about any topic: they're organized in a way that makes sense and it's easy for people who already know the topic
I think that the reason for a manual existence. To have a written record so we don't have to trust our memory. This is what most unix manuals are. You already know what the software can do, you just need to remember the specificity on how to get something done.
> often very bad at teaching the same topics to an audience that doesn't know anything.
What you need then is a tutorial (beginner seeking to learn) or a guide (beginner/intermediate seeking to do). Manuals in this case only serve to have better questions (Now you know what you don't know).
Re: Traps to Developers
#5CSS and C++ both have the “pick a subset and enforce that, or suffer” nature. On my to-do list: make a github action that requires manual override to merge any pull request with a css attribute not already present
Re: Traps to Developers
#6A recent trap for me: Regex semantics is subtly different across languages. E.g. a{,3} matches between 0 and 3 "a" characters in Python. In JavaScript it matches the literal string "a{,3}".
Regex is more a technique than an actual specification. It would be best to find the time to go and read an introductory book about Theory of Computation where they explain the underlying mechanism.
Re: Traps to Developers
#7A recent trap for me: Regex semantics is subtly different across languages. E.g. a{,3} matches between 0 and 3 "a" characters in Python. In JavaScript it matches the literal string "a{,3}".
I always use regex101 to develop my regexes. It allows you to switch between different engines.
Re: Traps to Developers
#8The first "trap" on the page says "min-width: auto makes min width determined by content", but this is false outside of flex/grid.
From MDN: "For block boxes, inline boxes, inline blocks, and all table layout boxes auto resolves to 0."
Re: Traps to Developers
#9The first "trap" on the page says "min-width: auto makes min width determined by content", but this is false outside of flex/grid. From MDN: "For block boxes, inline boxes, inline blocks, and all table layout boxes auto resolves to 0." https://developer.mozilla.org/en-US/docs/Web/CSS/min-width
[deleted]
Re: Traps to Developers
#10The first "trap" on the page says "min-width: auto makes min width determined by content", but this is false outside of flex/grid. From MDN: "For block boxes, inline boxes, inline blocks, and all table layout boxes auto resolves to 0." https://developer.mozilla.org/en-US/docs/Web/CSS/min-width
I guess the first trap should really be: "You cannot read any CSS property in isolation, as just like what the name implies, defaults and what values end up doing cascades through all the rules your document ends up using"