Anyone who feels otherwise has obviously not spent time in kernel land
I'll just note here that while the asm6 rewrite could be used by anyone, the target kind of is NESmaker users. So yes, they most certainly have not. So, is it then a good idea to assume the usecase of people that have been in the game for decades and are likely using ca65 or some commercial assembler?
My comment was specifically with regards to people whinging over the "readability of these lines of code". If the above .byte
lines are "hard to read" then the viewer seems to not know what's worse. In contrast, those lines are quite readable. It just goes to show that age and experience play a huge role in interpretation of what's considered "unreadable".
FrankenGraphics wrote:the most common shorthand for pointer ought to be ptr. i see it everywhere. but if you've seen p being used frequently, i'll take your word for it.
What you want (re: "ought to be") isn't what history has shown. Where do I begin? A good start would be to look at literally anything Microsoft writes especially for Windows. They adhere almost exclusively to what's called Hungarian notation
. Let me know if you need further evidence (ex. source examples from other projects, e.g. Linux, FreeBSD, etc) as I can drop tons of it fairly quickly. Likewise, s
prefix (sometimes str
) is often used to indicate string, and a _t
suffix is common for typedefs (here's why
FrankenGraphics wrote:Not saying the p prefix is the best idea or even a good one, just that something like it would be short and sweet.
Okay let me be very clear here: "short and sweet" is not always the best choice for naming conventions. What's really needed here it a clear way to convey to the person looking at the code (which could be either a person trying to improve Pently, or -- and I suspect this is much more likely -- someone trying to troubleshoot something) that "this thing relates to Pently". You cannot do that with a single byte. Or even two or three.
Furthermore, you are not gaining anything "technically" by using strict shorthand convention like this. This is an assembled program, not an interpreted or scripting language that's spending excessively more CPU time the longer the label/string/thing. This has been talked about extensively over the years.
That said, I am an equally strong opponent of excessivelyStupidFunctionNamesThatAlsoUseCamelCasingAndAreLongAsHell
. This is just as bad as the former. People who do this seem to be driven by fear of using comments, and attempt to convey the entire purpose of the world in the function name alone. I don't know how this became a strangely commonplace thing (is it education? Lack of? Or maybe just a lack of someone telling them why this is bad), but it's terrible.
But there's another reason, often overlooked, to use appropriately-descriptive names for labels/variables/things: the likelihood that an author won't understand or remember the code in the future. I cannot stress the importance of this one. This is not me projecting personal experience, it's a very real situation. Just because those variables and the "why" behind a function/thing makes sense today doesn't mean a year from now that you'll remember. Naming things "sanely" is a benefit not only for others (for collaborative projects), but also for yourself
as a prefix seems pretty damn good to me.
Else I direct you to https://thedailywtf.com/
for further programming horror stories.
FrankenGraphics wrote:The more letters in a const or var (or label) the more likely you'll typo it or forget some uppercase. And as we know since recently, unless it qualifies as a more explicit error like a missing argument or the like, asm6 will treat typos as labels and go along happily.
By that line of logic, you'd love brainfuck
. And ironically, Loopy -- author of asm6 -- has a well-established history of using pedantically short names for his variables (often 1 or 2 letters) -- oh, and p
for pointers too (example
) -- not to mention his "skinny on NES scrolling"
which while revolutionised accurate PPU emulation, was -- and still is -- one of the most indecipherable documents to date. There's a reason this Wiki page
is so long in contrast, and why there's a colourised summary: because it's really damn hard to understand with single-letter things.
is perfectly reasonable; parts of the C code
are just as bad. Go ahead and skim that code and let me know your thoughts on its legibility.
TL;DR -- Less character means less typos is not inherently true, use sanely-named variables/labels for things not excess in length but not too short, write code that's legible operating under the assumption others will need to look at it *and yourself in the future*, and programming in general is terrible.