Regarding the scripts folder, and coding style peculiarities

[cipriancraciun]

In reply to @xfbs on issue #12

Btw, how do the scripts in the scripts folder work? I noticed that you seem to be doing some amount of code autogeneration (looks like there is a bunch of whitespace in the sources, too) but I haven't been able to make sense of how it ties together?

With regard the scripts folder: that's my own personal console-based IDE customized for this project, based on another tool of my own, z-run. :)

In essence I use them to build, test, release, generate some non-essential files, grep the sources for problematic lines, etc.

However, they are absolutenly not required for building the tool. One can just go in the sources folder and run cargo build --release without any issues.

---

(looks like there is a bunch of whitespace in the sources, too)

Could you elaborate more on this?

[xfbs]

I don't want to a a whole code review, I just peeked into it to get a rough idea of what you're doing, and I noticed a few unusual things. Maybe they are intentional, maybe not, so I figured I'd ask.

In a lot of source files, there is redundant whitespace (as in, more than one empty line). Examples:

• https://github.com/volution/z-tokens/blob/development/sources/tools.rs#L17-L20
• https://github.com/volution/z-tokens/blob/development/sources/patterns_tokens.rs#L9-L12
• https://github.com/volution/z-tokens/blob/development/sources/memory.rs#L28-L35

That is why I was wondering if a lot of the code was auto-generated, that usually happens to me when I have code that is auto-generated.

Another thing I have noticed is hex constants in places, not sure where they come from. Might make sense to give them a name, as in define a const?

• https://github.com/volution/z-tokens/blob/development/sources/tools_generate.rs#L21
• https://github.com/volution/z-tokens/blob/development/sources/tools_generate.rs#L22
• https://github.com/volution/z-tokens/blob/development/sources/tools_generate.rs#L55
• https://github.com/volution/z-tokens/blob/development/sources/tools_generate.rs#L78

In a lot of places, the formatting seems a bit off. Like there being spaces after "Some" or before opening parenthesis. I think you should consider running the code base through cargo fmt.

• https://github.com/volution/z-tokens/blob/development/sources/tools_generate.rs#L21

Finally, one thing that I found makes it hard to follow the code is importing the prelude in files. Usually, when I write crates I will try to always import everything I'm using explicitly. This makes it easier to see where things come from (example: I was trying to see what the Rb type was in the code you had linked, but instead of seeing it directly imported from memory.rs, I had to follow through the prelude). I would recommend not internally using a prelude, offering it only to other crates linking against yours. But I suppose this is opinionated.

Cheers,
Patrick

[cipriancraciun]

I don't want to a a whole code review, I just peeked into it to get a rough idea of what you're doing, and I noticed a few unusual things. Maybe they are intentional, maybe not, so I figured I'd ask.

That's fine. Glad to answer.

---

In a lot of source files, there is redundant whitespace (as in, more than one empty line). Examples:

• https://github.com/volution/z-tokens/blob/development/sources/tools.rs#L17-L20
• [...]

That is why I was wondering if a lot of the code was auto-generated, that usually happens to me when I have code that is auto-generated.

Those spaces are there by "design", in the sense that I use a code editor that shows white spaces, thus having empty lines looks "strange". :)

For example this is how it looks in my editor (colors are stripped) (the ---> means a tab):

 --->
 --->print_and_exit (&[
 --->--->--->
 --->--->--->& format! ("* tool          : {}\n", _executable_name),
 --->--->--->
 --->--->--->#[ cfg (feature = "zt-embedded-build-meta") ]
 --->--->--->& format! ("* version       : {}\n", _build_version),
 --->--->--->
 --->--->--->& if _executable0 == _executable {
 --->--->--->--->format! ("* executable    : {}\n", _executable.display ())
 --->--->--->} else {

---

Another thing I have noticed is hex constants in places, not sure where they come from. Might make sense to give them a name, as in define a const?

• https://github.com/volution/z-tokens/blob/development/sources/tools_generate.rs#L21
• [...]

These are unique error codes, that would be displayed on the console when the tool fails. Thus, if one reports the error message, which should contain that code, I can just grep the source code to see where it originated.

Think of these codes as the usual __FILE__:__LINE__, but with my codes it's shorter and they don't change when the source changes (with __FILE__:__LINE__ I also need to know the actual source code used.)

I can't extract them into consts, because they are used in exactly one place. (There is actually a script that greps and makes sure they are unique.)

Granted, a proper error message would do, but I can't put one in every place the code fails, and at the beginning I don't have the time to put them in important places. :)

---

In a lot of places, the formatting seems a bit off. Like there being spaces after "Some" or before opening parenthesis. I think you should consider running the code base through cargo fmt.

• https://github.com/volution/z-tokens/blob/development/sources/tools_generate.rs#L21

Yeah... I have a very "unusual" way of writing code... The problem is that I write code in a lot of languages, like Erlang, Go, Python, Bash (yes I do consider it a programming language), etc.

So I tried to develop a code format that can fit all of these languages with all of their particularities.

With regard the extra spaces around parentheses, although none of the languages require them, I find them extremely useful to see the expressions.

Passing my code through cargo fmt would break everything. (And last time I looked, there isn't enough configuration to match my style.)

---

Finally, one thing that I found makes it hard to follow the code is importing the prelude in files. Usually, when I write crates I will try to always import everything I'm using explicitly. This makes it easier to see where things come from (example: I was trying to see what the Rb type was in the code you had linked, but instead of seeing it directly imported from memory.rs, I had to follow through the prelude). I would recommend not internally using a prelude, offering it only to other crates linking against yours. But I suppose this is opinionated.

I completely agree with you on this point regarding prelude modules or use some_module::*.

I agree it does make the code extremely hard to follow. And I do have the same problems when looking at other people code.

However, I hate to write endless use some_module::Something_A;... (I use a plain-text editor that knows nothing about Rust, thus I'll have to write these by hand.)

Also, when moving code around I just want to ignore the use statements. Thus all my Rust projects have a prelude module where I import everything, and then in all my modules I just import use crate::prelude::*. It makes my life so easy... :)

So, although I agree with you on the readability issue, on this one the practical aspect wins hands down. :)

---

However, all that being said, if this project becomes popular, or it gains serious contributors, I am definitively willing to address all these.

But at the moment, being just me, I like to make my own life easier. :)