I found this tool: https://git.sr.ht/~rabbits/lin6 - however, it doesn't support "new" CMOS Rockwell/WDC instructions. I've considered submitting a patch, however I decided to ask here first in case anyone uses some tested tool:

> Do you folks use any 6502 assembly linters?

This "lin6" that I mentioned seems to have some minor quirks (like adding a trailing whitespace for instructions with implied addressing) and last commit seems to be circa 2 years ago, so I'm trying to decide whether it's worth trying to improve this tool. Also, it's more of a code formatter rather than a linter.

"But why?"
- I love linters/fixers.
- I'm too used to my own assembly code style (lower-cased instructions, multiple indentation levels, etc), and I often find it hard to understand other people's code because of that. Linter will help me adapt my coding style to what most people on these forums use, and thus make it easier for me to comprehend other people's code (as well as make myself more consistent with the rest of the community.)
- Linter/formatter can sometimes help to find nasty typos by amplifying their visibility.

Example of code that's reformatted:





Edit: just noticed that lin6 swallowed some ".res" commands and also uses tabs instead of spaces... Might need way more work than I anticipated.

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

If you like it, use it! There will certainly be people who are not interested. But if you're interested, and the person who wrote it was interested, there will be others too.

(I'm generally happy once my source files are accepted by the tool I'm using, but in principle I like the idea of pretty-printing, and stricter checks like those a linter might do.)

I've recently been playing with a library called Lark (https://github.com/lark-parser/lark) - it allows to process grammars using EBNF (and few others) and use them to parse arbitrary input.

I'm calling my new thing "nice65". I've spent around an hour to build a quick PoC and added some extremely basic grammar for CC65 assembly language.
All my code is hosted here: https://github.com/and3rson/nice65
Currently it can reformat some very simple code/labels/comments. And it's only around 100 lines of Python code so far, most of which are the formal definition of CA65 grammar.




I'll be trying to improve it, my to-do features are:
- Reliable processing of assembly code without occasionally messing things up
- Support for CA65 macros & control commands
- Differentiating & respecting top-level comments (i. e. function docstring - "; Add two numbers and return result") versus context comments (e. g. "; return if buffer is empty"). This is important since it will allow nice65 to "understand" function boundaries in the code and add empty lines between them to make the code more comprehensible.
- Linter functionality, including warnings for potential mistakes/improvements (e. g. "missing RTS before global label", "JSR/RTS can be replaced with JMP", "Incorrect addrressing mode", etc).

I want to make this similar to Python's black (https://github.com/psf/black) - one set of sane rules with very little configuration.

Of course, it won't do static analysis as good as CA65, but it might still find lots of common errors that CA65 would silently ignore.

Question to the community: I'd like to conduct a small questionnaire to hear your thoughts on what a "perfect" 6502 assembly code style looks like in your mind, for example:
- What indentation rules do you follow
- Do you use empty lines and how
- Tabs/spaces
- Uppercase/lowercase indentifiers
- Labels & instructions - one line or multiple, different indentation for global & local ("cheap") labels, etc.
- Maximum line length
- Your personal code style preferences for which you would like to have a configuration option

I know there probably won't be "one size fits all", but I think most of the above can be nicely compiled into what I'd call a "sane code style rules for 6502 ASM", while controversial preferences can be made into configurable options (e. g. maximum line length, comment wrapping, etc). Looking forward to your thoughts!

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Ask 10 programmers, get 11 answers...



My own but generally labels start in column 1, mnemonics start in column 8 and comments are typically lined up...



Yes. I press the enter key, that's how, but I suspect that's not the answer you want.



Yes, I use these. I'm not fussy about (hard) tabs or spaces - editors sort it out for me. I like a variant of camelCase where the first character is lower case, but I use upper case to separate words. Things in ALL CAPITALS are generally constants or something that needs to stand out.



Yes, I use them and want them. Labels start in column 1...




It's 2023. Why impose a limit?



My style works for me.



Your rules will be different from other peoples rules - that's the issue, and people tend to have "brand loyalty" too - When I got back into 6502 coding, I got used to as65 (from the cc65 suite) and now use it exclusively - it works for me and gives me almost everything I want - and for the 0.1% It won't do, I write a program to output asm in the way it wants. Prior to that - I used BBC Basic and TED II+ on the Apple II, and the Apple mini-assembler ...

The hardest crowd to please are (IMO) the Acorn/BBCMicro folks. They have an assembler built into BBC Basic that's actually pretty amazing to use once you get used to writing your code inside a BASIC wrapper.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thanks for your inputs. I guess my choice of word "questionnaire" was not entirely correct since I don't have a precise list of possible options for each question and am simply trying to understand general coding tendencies across the community.

Looks like I'll just make most options configurable in case you folks decide to use my tool in future. For now, I'll refer to what you provided and try to move from there.

BTW, colon-less labels were a pain to implement! Though they helped me to get better with Lark and to find more oversights in my grammar definition.
I initially aimed to support only colon-terminated labels, but I really wanted to see if my formatter would work with C64 sources. With some fixes, I was able to run nice65 on entire C64 Basic & Kernal codebase - https://github.com/mist64/c64rom - and it successfully compiled with CA65 afterwards (checksums of ROMs remained unchanged). I'll probably post the reformatted code somewhere as a proof (if Mist64 will allow this).

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD