Possibly naive/metaprogrammer take on style guides: we should share code as ASTs & every user should bring their own pretty printer (style preferences) to how they view it as text.
Yes, even to how names/ids are compounded from word chains.

I definitely agree with that (so the only style left would be identifier names).

I don't know how common AST code viewers are and how well they integrate with version control though.

I had a few minutes so I wrote up a basic outline of this in more detail. I'm certainly not the first person to think of this but it's a shame I've never seen it gain widespread support.

@shivoa Hmm good thought. Probably the reason is inertia; large parts of programming have not changed for decades in this regard. For example, why I can't put pictures into code comments (diagrams, explanations, etc.)? And so on.

@hannah @shivoa That's no problem. I use VS Code as my default editor, but I include Vim controls. ;-) The source code performs clang-format checks that verify all merged code uses tabs, so I've gotten pretty used to that style now.

That said, it also does a weird mix of pythonic naming conventions inside C++. Typenames are PascalCase, but variables and functions are in snake_case.

@willnationsdev @shivoa @hannah
Why weird? PascalCase for classes, snake_case for identifiers and ALLCAPS for constants is pretty standard in C++ code, at least as much as camelCase for identifiers. Most C libraries use snake_case so C++ follows along.

@akien @hannah @shivoa Really? I never knew that. Granted, I'm not the most experienced programmer. Only been programming for, like, 6 years, 4 of which were in college devoted exclusively to camelCase conventions (I didn't even mess with Python-like syntax until I started learning GDScript earlier this year).

I've grown accustomed to it, but I had thought it was something born simply out of your guys' preference for Python syntax and tooling, etc. Good to know it's more commonplace.

@shivoa @hannah @akien Wait, that's not entirely true. My first experience with programming was GameMaker Language, which uses snake_case. But I only dabbled with it briefly since I was still not sure I could make it as a programmer at the time.

I went into college to be a Christian missionary in Japan, and then 1-year in I realized I needed to find a major that'd allow me to feed myself, and I tried out programming. Lo-and-behold, I enjoyed it immensely (and was ok at it).

@akien @shivoa @willnationsdev I think that camelCase works best for C++ but snake_case was used in C due to the lack of classes so names would actually be the sole way of organising code.Functions like libname_create_http_handler() and stuff are a relic of C that has made its way into modern C++.

That being said I'm a C# programmer so it's all rather uncivilised as far as I'm concerned ;)

@shivoa @aras I have a friend who works somewhere where they use resharper (or similar) to convert all code to house style on commit & they have hooks to allow individuals to re-format into their preferred format when source is pulled from the server.

It's not quite the "store source as ASTs" nirvana you're proposing, but it is doable right now :)

@darbotron Yep, I really hope that workflow appears in a standard VCS platform/tools in the near future. Once it becomes widespread, I don't see many going back.

@shivoa If the language is complex this puts quite a burden on the text-editors - or at least needs some std way of (de)decorating the AST, maybe leveraging the compiler, unless you're locked into one IDE.

I do see a problem with this though: the programmer might become less flexible, by requiring a personal pretty printer set up. It might not always be possible. Some people claim they _cannot work_ w/o VisualAssist/Emacs/Xcode/ReSharper or whatever.

@jakob I'd say that now (with code standards) we're already getting that inflexibility with none of the benefit of seeing code how we prefer to format it. AST as shared should definitely include a std PP so everyone can import text into preferred IDE/editor.

@shivoa @jakob I think so many syntactic style differences say something about the language: That the core syntax is bad. Not fairly bad, like super bad. I haven't seen Lisp community differ/argue over style for a single line of code. I would argue a good language syntax is one that doesn't make community suffer over syntactic issues.

@jakob @shivoa Why trying to represent the language at a non-standard AST level instead of defining the language syntax in a way that is closer to the AST but still very readable.

@shivoa @jakob Also, the name/id composition idea is really really bad. It effectively makes API's, too. Why? The more we get used to this much dynamism over syntax, the more it gets harder for us to read someone elses code. Are we going to share code blocks in blog posts as AST as well? Are we all going to use plugins that prints code blocks in blogs according to our prefs? Text is a good middle-ground. The problem is not text.

@kenanb That's an example of how far we could go (if desired) because why restrict it? Why fight over camel vs snake if we both just want to compose names from words? Obviously text will not go away, but this effectively is another way of decorating code to preference of each user.

@shivoa Because the same focus on personal preference also brough us the ability to put const before or after the type name. The whole problem is too much flexibility in how we can write it. And the perceived density of text is very context dependent. I feel the same need to modify how a block of code is spread over lines in C++, I don't in Lisp or Factor. Because in those langs, there is some kind of correlation between text and the code.

@shivoa I understand the urge to get rid of all these stylistic arguments once and for all. But you are doing that by effectively removing the syntax redundant altogether. Once you store it in AST, you don't need ANY SYNTAX at all. Do that, and people will start writing "readable AST presentations" for convenience. Some, like me, will use Lisp-like C++. Some C-like. They will be effectively the same thing as language syntax :) The truth is, we need uniform textual code representations.

@kenanb @jakob Think some is natural variation in preference. Coder who prefers dense text vs someone with portrait screen and lots of height to spend on vertical whitespace; long lines vs reading over breaks. Coder who adds more parentheses to equations to avoid mistake vs someone who has memorised priority. Would rather build tools for everyone.

Sign in to participate in the conversation
Gamedev Mastodon

Game development! Discussions about game development and related fields, and/or by game developers and related professions.