I find myself reading text and symbols like { }, + 1 and l all jump out of the text immediately. Not sure if it's just me or if our eyes are faster at matching bracket pairs and stuff.
Posted Jan 11, 2022, 7:52 AM UTC
I feel like If lost the ability to read after many years of programming. I just fly over some text, see some words and interpolate the rest xd.
I didn't read the mid-part of your comment, but I agree with that statement.
I agree!!
As someone from Europe, the dollar sign always trips me while reading, since 99% of the time I encounter it, it's in bash scripts.
Same. We should have €VARs over here.
(kidding, please, please don't)
Jokes aside, WRT variables in languages, I really like cljs ( Clojurescript - just, from what I'm familiar with...) in which a variable can include special characters. I especially like it when it comes to boolean conditionals. I find reducing to even? and odd? as opposed to say isEven or, perhaps worse, notEven or notOdd just way more pleasing and in my mind, more ubiquitous and professional when it comes to trying to understand someone else's code. Not to mention, more expressive/potential to express.
While I support the idea of having special characters in variable names in general (even though I'm not using them) the caveat here would be that odd? often means something completely different on nullable languages like C# or Typescript.
not sure I follow.
One of the early advances in reading is that you recognise whole words: you don't have to spell things out to recognise the word. Also, you use context to limit the "auto-completion" in your head. This is why prooof-reading can be so hard: you don't see the mis-speling because you grok the whole word as one symbol.
When you are using a computer language intensively, you just learn to incorporate other characters into the words, like ${foo} or *(p + j) or [[:space:]].
you lost me after foo, lol. What are the other two?
Edit: (* p j) ..... is your middle one, possibly among things, bash? The latter kinda looks like a keyword of sorts.
"${foo}" is a Bash variable substitution. You can omit the quotes (but not if foo might contain spaces, because it becomes multiple words). You can leave out the braces (unless you want to us any of the 20 special expansion operators). I almost always write the whole thing anyway, because it just shouts "variable expansion" in my ear. I figure any fool can write shell commands: it is the variable data that you really need to watch out for.
*(p + j) is a C pointer relative adjustment. It is equivalent to p[j] (a normal index to an array). I don't mind that way when you declared p as an array, like double p[20]; but if a function gets passes that array through a pointer p, I tend to write it the first way to remind myself that the function does not know the actual array size.
[[:space:]] in Bash is an example of a pattern using a character class, which works in any locale (language). This one matches any of six different white-space chars in the C and POSIX locale, but in (say) UTF-8 it would match other chars like non-breaking-space.
All these things are units that are almost a picture of what is going on. I like my code to look pretty on the page. All that indentation, whitespace, and comments are for people, not for the compiler (Python excepted). A mechanic who leaves his tools wherever he last used them will not be as good as the one who puts them back in the rack.
That's probably just the OCD talking, right enough.
So, firstly I hear where you're coming from - and from a seasoned programmer, which it sounds like you are, I imagine an elegant "[[:space:]]" is wonderful.
I'm not sure though if I follow the logic WRT pointers above, though, I don't know much c/c++. Is it the error handling you're relying upon or something else? bc the way I see it, indexing out-of-range given len(p) and value of j would result in an error regardless. How does it help, per say? Or how is it "slicing", if at all? If I understand *(p+j) is the pointer to the j-th item/index of the array p. Not sure I follow... (disclaimer: I really love the lower level stuff. If this "notation equivalency" of sorts has some practical application, I'd love to understand it :-).
Muchos Gracias for the explanation though and some things to consider..
Edit: accidentally ctrl+entered too early. Just wanted to say lastly, I disagree with your last point. From my own experience and how I've been taught. All the human readable aspects are probably the more important part of things than anything. At the very least, the code needs to be maintained, and even verbose code that at least compiles nicely is better than short code, imo. Besides, lots of languages, js and python included, can be minified extensively, and generally are anyway (specifically wrt the interpreted languages). At the end of the day, language extrapolations and substitions etc generally allow for a human-readable centric approach to writing code, which I think is better for professional environment, this is just my opinion of course.
Final edit (actual edit this time):
as a simple example python code of the kind [print a for a in client names] reads wonderfully but in my experience performs poorly. It's concise and "pythonic", least, I think it is, but just not performant
Or when you start making sure your brackets are all paired in a text to a friend lol
Can't have a syntax error prevent your friend from interpreting your text. Understood Lol