[TUHS] Re: What would early alternatives to C have been?

Sent with Proton Mail secure email. On Monday, March 10th, 2025 at 9:30 AM, arnold(a)skeeve.com <arnold(a)skeeve.com> wrote: I'm quite enjoying following along in this thread as my current work team is in a growth pattern. For the first year of the project it was mainly just myself and my manager slinging code. We had been bumped over from the same project so already had a pretty good synergy. Then we brought in a few new folks and managed to settle into a good groove, we weren't using automated style enforcement but didn't tend to step on each others toes. This year the team has expanded both a few times over in numbers as well as in geographic footprint and the divergences in approach are finally becoming "a thing" that needs to be addressed intentionally rather than organically. It's proving quite a pain, I used to be a stickler for style and have in the past several years tried to relax that attitude...which now with the growing need to pay attention to that again, it's a bit jarring to now see the pendulum swing in the opposite direction. I generally like deferring to folks tasked with a problem to come up with all the minutiae surrounding their solution, but with the size our team is growing to, I'm coming to recognize where having those structural guardrails saves everyone headaches in the long run. Generally I'm a more parens is fine if it makes meaning clear kind of person, annoyingly though with some assembler projects. Since parentheses are more context-sensitive in different assembler languages, I've found plenty of situations where I use parentheses in a macro or equate definition only to find later when they're used with some operation, they trigger an addressing mode that I didn't intend. - Matt G.