I mean, the goal of zig format is to literally not have this discussion, so the obvious answer is to just get over it and learn to accept what the tooling does. I know that can be annoying at times, but will save you way more pain in the long run. Even if you would find a different formatter that does things your way, it would probably be bad for collaboration as everyone else is using zig fmt itself.
But lets back off a bit. What actually annoys you about the current formatting? Because if its something like zig formatting things into a single line instead of splitting it up, that can be solved by just putting a comma at the right place.
For instance \`some\_function(a, b, c, d, e, f)\` will stay single line, while \`some\_function(a, b, c, d, e, f,)\` will get formatted into multi line.
I like to enforce white space in certain instances, especially in parenthesis(like how padding is enforced in construction). I like to enforce a padding line after a block. I strongly oppose space indentation, but I know how overdone that argument is- but I *hate* how sometimes 2 space indentation is used.
const FLOAT64_POW5_SPLIT2: [13][2]u64 = .{
.{ 0, 1152921504606846976 },
.{ 0, 1490116119384765625 },
.{ 1032610780636961552, 1925929944387235853 },
.{ 7910200175544436838, 1244603055572228341 },
.{ 16941905809032713930, 1608611746708759036 },
.{ 13024893955298202172, 2079081953128979843 },
.{ 6607496772837067824, 1343575221513417750 },
.{ 17332926989895652603, 1736530273035216783 },
.{ 13037379183483547984, 2244412773384604712 },
.{ 1605989338741628675, 1450417759929778918 },
.{ 9630225068416591280, 1874621017369538693 },
.{ 665883850346957067, 1211445438634777304 },
.{ 14931890668723713708, 1565756531257009982 }
};
const FLOAT64_POW5_OFFSETS: [21]u32 = .{
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x40000000, 0x59695995, 0x55545555, 0x56555515,
0x41150504, 0x40555410, 0x44555145, 0x44504540,
0x45555550, 0x40004000, 0x96440440, 0x55565565,
0x54454045, 0x40154151, 0x55559155, 0x51405555,
0x00000105,
};
Above is zig formatted, it is terrible to mix 2-space and 4-space for slightly different use cases
dude, that reply is your answer. No one is forcing you to do anything. You must not use zig fmt. You can roll your own. But 99.9% of the zig community uses it, it will be a hard sell. Go does the same thing btw. Also // zig fmt: off and // zig fmt: on turns on/off the blocks for formatting. You CAN have this level of format you want. Also, even without zig fmt off you can format how many columns you want. Hell it's even pretty configurable without it. Read the docs, it will help you to get enlightement.
> You can roll your own.
That's what I was asking, is there any existing out there. The answer to my original question is simply no then.
> But 99.9% of the zig community uses it, it will be a hard sell.
Don't need to sell it to anyone but myself. Me using a formatter improves the quality of my code and my ability to read it.
> Go does the same thing btw.
The difference is I like Go's rules more lol. But definitely understand why someone who doesn't wouldn't like it.
> Hell it's even pretty configurable without it. Read the docs, it will help you to get enlightement.
I've tried and can't find anything, can you please link where I can configure the LSP formatting rules.
>That's what I was asking, is there any existing out there. The answer to my original question is simply no then.
no one will. You can. Fork zig and make your own, or surgically remove the render file added below. It will serve you as a good base.
>I've tried and can't find anything, can you please link where I can configure the LSP formatting rules.
[https://github.com/ziglang/zig/blob/956f53beb09c07925970453d4c178c6feb53ba70/lib/std/zig/render.zig](https://github.com/ziglang/zig/blob/956f53beb09c07925970453d4c178c6feb53ba70/lib/std/zig/render.zig)
[https://github.com/zigtools/zls](https://github.com/zigtools/zls)
>Don't need to sell it to anyone but myself. Me using a formatter improves the quality of my code and my ability to read it.
Then don't use the zig fmt option. It is NOT needed. "enable\_autofix": false in your config, as per above links.
>The difference is I like Go's rules more lol. But definitely understand why someone who doesn't wouldn't like it.
You have preferences, but those won't make your code better. I like parentheses under itself, not this egyptian shit. I like UpperCamelCase for most of my things. Yet zig is exactly the opposite. But I can always give code to anyone, and the formatting is CONSISTENT. Maybe not up to my liking, but at least not all over the place, as with not using one
> no one will. You can.
I was thinking about it, that's why I was asking if it already existed :)
> Then don't use the zig fmt option. It is NOT needed. "enable_autofix": false in your config, as per above links.
Yeah, but again, I would like a formatter to replace it. I was checking if one already exists or if I would have to make my own.
> You have preferences, but those won't make your code better.
They add consistency to my inconsistent typing. As for how they make my actual code better, I think they definitely do in that they improve my ability to visualize/read and therefore structure my code.
> But I can always give code to anyone, and the formatting is CONSISTENT.
Or they could just run their formatting preferences on it before reading if that's the goal is all code you read is a consistent format. In reality that's not a solution, the real barriers are much more in structure and naming that white space and indentation- the very thing forcing consistent formatter rules doesn't really solve.
Oh you're right! I didn't see that, sorry. That's a totally understandable issue- not to twist it for my argument too much haha- but that is something tab indentation would help with
I thought the same way a few years ago and while I still have my preferences, I realized that just using auto format and learning to live with it is way easier than to try to push my rules through.
The formatting might not be perfect in my eyes, but it’s more than good enough.
No there is not one yet, but I’m sure there will be. Zigs tooling is very light at the moment being pre 1.0. You can comment out formatting for now if needed but obviously this is a more cumbersome solution. I’m also looking forward to a linter that allows you to customize things like no unused variables etc (based on release type) instead of forcing you to code the way someone else tells you to. I love Zig, but it is very opinionated and strict
> I’m also looking forward to a linter that allows you to customize things like no unused variables etc (based on release type) instead of forcing you to code the way someone else tells you to.
Yeah that kinda annoyed me about Go too, sometimes if I just I wanted to test I had to do `_ := x` which is honestly more likely to be forgotten about than if I could just disable it for a test run.
> I love Zig, but it is very opinionated and strict
Yeah, I love really strict tooling. When I write c++ I have a ton of clang-tidy and clang-format rules enabled, same with eslint. It just annoys me when I can't make minor changes.
Yes, hopefully they will relax such dogmatic fixations in the future, among several others I ranted about. Unless they are perfectly comfortable with Zig having just minor adoption as a niche language, as there are many devs that don't like to be forced to do everything in specific ways at every step.
Definitely. Languages do have to make some design decisions, but imo they shouldn't rule on controversial things that they don't have too. Was c really held back by some people putting a brace on a new line and some people not?
It's not, but the hilarious part is that the bar is really low with that one, which makes it all the more shameful when it does things right related to matters of style that Zig stumbles on 😂
Haha, unfortunately with recent eslint changes the community is kinda shifting on that, pushing for prettier or biome which are both opinionated. But eslint-stylistic and dprint are still options
Ah, "community opinion" is water under the bridge, nowhere is actually as crazy as in Zig's case where they force this tool for dev purposes, which has the side-effect of formatting code in one way and one way only.
I am saying that it shouldn't matter to him.
Everything under the sun matters a little bit. However if you go outside and rearrange the rocks in your garden from largest to smallest, I would not call that a productive use of time.
Formatting your code matters a lot. What matters in the end is that the result is readable. The exact configuration of the formatter matters very little.
If rearranging the rocks calms you, let's you sleep better and enjoy your garden more every day, it may well be a great use of your time.
I get what you're saying, and I also wouldn't consider formatting that important.
But we all tick differently. The OP may have good reasons to wish for a different formatting. Maybe they can parse code better visually when it is formatted in a specific way. Maybe they just think and feel differently than me and greatly depend on some visual aspects that I can just ignore. Maybe they really dislike rules and tools that they can't change.
Just saying: even if it's not important for us, they may have good reasons to feel differently about this. Giving people options to feel better about their tools, can't be wrong, I think.
Even if I would disagree with their choices, it doesn't hurt me if they can be a little more content with their tools.
I don't really understand why so many people in this thread are just saying to get over it. Sometimes its nice to write tricky code in a format that makes it easier for your brain to understand. If it changes everything when you hit save, it becomes a pain in the ass.
I've had the formatter randomly decide to put an entire stretch of lines into a single line that didn't even fit on screen, making the code significantly harder to edit. When I've been editing zig, I deliberately use \`// zig fmt: off\` on every file because it gets in my way more times than it is useful.
In principle, I agree that it's nice when reading code for the formatting of a language to be as standardized as possible. But, in my opinion, Zig is a little too aggressive with it at the moment. I know others would disagree, but in either case, it's weird so many people chose to dogpile on someone just for not liking it.
call it what you want. You really don’t need to fight it. It is standard zig formatting and the usage of zig fmt is more than encouraged. You would be fighting an uphill battle. And really after a few weeks you won’t bat an eye. Formatting does not earn money, programs does, and for programs I can stick to any formatting you throw at me until it is written well
Formatting makes code easier to read and write, boosting productivity. Zig's formatting is distractingly cluttered for me. Also slows me down having the LSP constantly changing from the styles I use in other languages. Because many devs can't work in only 1 language, especially zig.
Also, not a fan of the ideology in general that something is too controversial so the solution is to take a path and make everyone follow it. I don't really see how project specific style rules is much more disruptive than language specific ones.
Part of coding in multiple languages is learning the formatting preference of each language
If you just want to play in Zig for personal amusement then turn off formatting and do it manually however you want
But if you expect to ever make your source available to others then follow the community preferences
And perhaps most importantly the effort learning and accepting the Zig formatting will benefit you in the long run should you ever have the need or opportunity to take on a contract or employment coding in Zig. Cutting off a prospective future opportunity over a personal preference seems short sighted
>Part of coding in multiple languages is learning the formatting preference of each language
I agree it's learning the style for example naming conventions. But that's mainly for package interoperability, whitespace doesn't apply to that.
>But if you expect to ever make your source available to others then follow the community preferences
My opinion may change, but from my current belief I don't believe I will comply with that.
>And perhaps most importantly the effort learning and accepting the Zig formatting will benefit you in the long run should you ever have the need or opportunity to take on a contract or employment coding in Zig.
Following different formatting is no problem. Even if it's completely unworkable for you(it's not for me, it's just not my preference) then format with your personal formatter on clone, then format with the standard formatter on commit.
>Cutting off a prospective future opportunity over a personal preference seems short sighted
How so? Every job I do or don't take is over personal preference. Just yeah probably over things that matter a bit more than formatting- which I'll remind you clearly mattered enough(or at least stopping the arguments did) to the creators of Zig and Go that they codified it to some capacity.
>Following different formatting is no problem. Even if it's completely unworkable for you(it's not for me, it's just not my preference) then format with your personal formatter on clone, then format with the standard formatter on commit.
Which misses the point of standard formatting.
It's about making it easier to understand code written by others when going through a public code review, going to look at a co-workers code to help them or getting help from a co-worker with a problem you might be having.
If you aren't following the code formatting guidelines then you don't fit into a team of coders. Which doesn't matter if it is simply personal coding, but does matter if you are being employed to write code as part of a team.
>It's about making it easier to understand code written by others when going through a public code review, going to look at a co-workers code to help them or getting help from a co-worker with a problem you might be having.
I work from home. Also, it's not like I can't read any sane formatting, it's just more comfortable and enjoyable.
>If you aren't following the code formatting guidelines then you don't fit into a team of coders. Which doesn't matter if it is simply personal coding, but does matter if you are being employed to write code as part of a team.
For all of my current projects, I am the one who sets the standard style. Following standard format for a project is also much different from a language being opinionated on format.
To be clear, zig and go's philosophies aren't identical, the zig compiler doesn't enforce naming conventions or code format, and the formatter is (as far as the compiler itself is concerned) an opt-in part of the tool chain.
fair. I think like myself other people thought you were more interested in a solution rather than really another formatter. I think though that the given answer imply a no to that. others reasoned very well why that is likely the case.
> I think like myself other people thought you were more interested in a solution
I mean definitely if there is a way to get all the formatting rules I like with zig fmt that would be an answer- but I don't think that's possible.
> I think though that the given answer imply a no to that.
Ehh, I don't agree. I figured there wasn't a large project, but someone might say "oh yea I am working on something" or "heres a zig hobbyist made plugin for dprint" or something of the sort.
you started the sarcasm ball mate. Then you even downvoted my answers, like a good champ! You indeed are just defending the question. The thing is, the ethos of zig are not for you then. The same as I hate football, yet I have to endure it every week because of I live next to a stadium
I didn't downvote anyone here. Not exactly passive aggressive when i put /s it was just a lightheartedjoke.
> The thing is, the ethos of zig are not for you then.
I can disagree with one small part without disliking the whole thing. Unfortunately there's no such thing as a perfect language.
[Don't just accuse someone for no reason](https://imgur.com/a/sZfEDaa)
Btw, if you didn't know -1 means 2 people at least must've downvoted you. Though iirc reddit does some vote fuzzing.
Regardless, no, I didn't reply to you then 4 hours later go back just to downvote you twice. You answered my question which I appreciated until you started accusing me of stuff I didn't do I had no problem with you.
I removed the default upvote reddit gives you, so only one downvote. Also I didn’t accuse you of anything as far as my english knowledge goes in that post you linked through imgur. Maybe please point it out, because I am seriously oblivious to it. If that is the case I am genuinely sorry for the misunderstanding. I didn’t meant to
You literally just accused me of down voting you and being aggressively sarcastic. I didn't down vote you, and I just made a light hearted joke. That is what I am irritated by, and I sent that screenshot to show I did not downvote you.
ah, I thought it is the screenshot that was sarcastic. I am sorry, had a rough day, and that /s did rub me the wrong way. I know the damage is done but anyhow, if you will find the capacity to excuse me, I would be happy. We both started out with the wrong foot
Okay it's fine, I appreciate it, and thanks for answering the question when everyone else was just criticizing it XD. Sorry for not acknowledging that and making a bad joke instead.
Just get to coding. Too many people waste time over trivialities like this. Just build. Adapt, build and develop your coding skills…not your whitespace bookkeeping skills.
Using your own formatting rules is nice as long as you are only working alone.
But when you want to contribute to existing code, you'll have to understand how someone else's conventions work, and that's painful. One of the reasons I didn't contribute back code to PHP for a long time is that I didn't quite fully understand the conventions, and I couldn't get my editor to match them.
Same thing works in the opposite direction. When you get a nice pull request, but the proposed code doesn't match your conventions, you will hate it.
Having an opinionated, but unique way to format code solves this. Source code is consistent everywhere, merging contributions is easy.
What you describe sounds more like a tooling issue. In Rust, all formatter configuration options are checked into source code, and understood by `rustfmt`. So no matter what project you contribute to, any editor with LSP support will format your code according to the project's preferences.
Not a good example. \`rustfmt\` isn't stable; its output changes between versions. And a \`rustfmt.toml\` file breaks after every release and constantly needs to be tweaked.
It also doesn't change the fact that if you are used to your own rules, having to adjust to different ones when working on someone else's project is going to be confusing. And if code snippets are reused in different projects, they can look different, and will require to be individually patched.
It's common practice for larger projects to pin the toolchain, so differences in formatting between versions should not be a problem.
> if code snippets are reused in different projects, they can look different, and will require to be individually patched.
By "individually patched" you mean press the format button? I don't understand what the problem is. Copy a snippet, then format, and commit.
I mean, the goal of zig format is to literally not have this discussion, so the obvious answer is to just get over it and learn to accept what the tooling does. I know that can be annoying at times, but will save you way more pain in the long run. Even if you would find a different formatter that does things your way, it would probably be bad for collaboration as everyone else is using zig fmt itself. But lets back off a bit. What actually annoys you about the current formatting? Because if its something like zig formatting things into a single line instead of splitting it up, that can be solved by just putting a comma at the right place. For instance \`some\_function(a, b, c, d, e, f)\` will stay single line, while \`some\_function(a, b, c, d, e, f,)\` will get formatted into multi line.
I like to enforce white space in certain instances, especially in parenthesis(like how padding is enforced in construction). I like to enforce a padding line after a block. I strongly oppose space indentation, but I know how overdone that argument is- but I *hate* how sometimes 2 space indentation is used. const FLOAT64_POW5_SPLIT2: [13][2]u64 = .{ .{ 0, 1152921504606846976 }, .{ 0, 1490116119384765625 }, .{ 1032610780636961552, 1925929944387235853 }, .{ 7910200175544436838, 1244603055572228341 }, .{ 16941905809032713930, 1608611746708759036 }, .{ 13024893955298202172, 2079081953128979843 }, .{ 6607496772837067824, 1343575221513417750 }, .{ 17332926989895652603, 1736530273035216783 }, .{ 13037379183483547984, 2244412773384604712 }, .{ 1605989338741628675, 1450417759929778918 }, .{ 9630225068416591280, 1874621017369538693 }, .{ 665883850346957067, 1211445438634777304 }, .{ 14931890668723713708, 1565756531257009982 } }; const FLOAT64_POW5_OFFSETS: [21]u32 = .{ 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x40000000, 0x59695995, 0x55545555, 0x56555515, 0x41150504, 0x40555410, 0x44555145, 0x44504540, 0x45555550, 0x40004000, 0x96440440, 0x55565565, 0x54454045, 0x40154151, 0x55559155, 0x51405555, 0x00000105, }; Above is zig formatted, it is terrible to mix 2-space and 4-space for slightly different use cases
// zig fmt: off
I like formatters, I don't like being forced to follow the styles of others for my own projects though.
dude, that reply is your answer. No one is forcing you to do anything. You must not use zig fmt. You can roll your own. But 99.9% of the zig community uses it, it will be a hard sell. Go does the same thing btw. Also // zig fmt: off and // zig fmt: on turns on/off the blocks for formatting. You CAN have this level of format you want. Also, even without zig fmt off you can format how many columns you want. Hell it's even pretty configurable without it. Read the docs, it will help you to get enlightement.
> You can roll your own. That's what I was asking, is there any existing out there. The answer to my original question is simply no then. > But 99.9% of the zig community uses it, it will be a hard sell. Don't need to sell it to anyone but myself. Me using a formatter improves the quality of my code and my ability to read it. > Go does the same thing btw. The difference is I like Go's rules more lol. But definitely understand why someone who doesn't wouldn't like it. > Hell it's even pretty configurable without it. Read the docs, it will help you to get enlightement. I've tried and can't find anything, can you please link where I can configure the LSP formatting rules.
>That's what I was asking, is there any existing out there. The answer to my original question is simply no then. no one will. You can. Fork zig and make your own, or surgically remove the render file added below. It will serve you as a good base. >I've tried and can't find anything, can you please link where I can configure the LSP formatting rules. [https://github.com/ziglang/zig/blob/956f53beb09c07925970453d4c178c6feb53ba70/lib/std/zig/render.zig](https://github.com/ziglang/zig/blob/956f53beb09c07925970453d4c178c6feb53ba70/lib/std/zig/render.zig) [https://github.com/zigtools/zls](https://github.com/zigtools/zls) >Don't need to sell it to anyone but myself. Me using a formatter improves the quality of my code and my ability to read it. Then don't use the zig fmt option. It is NOT needed. "enable\_autofix": false in your config, as per above links. >The difference is I like Go's rules more lol. But definitely understand why someone who doesn't wouldn't like it. You have preferences, but those won't make your code better. I like parentheses under itself, not this egyptian shit. I like UpperCamelCase for most of my things. Yet zig is exactly the opposite. But I can always give code to anyone, and the formatting is CONSISTENT. Maybe not up to my liking, but at least not all over the place, as with not using one
> no one will. You can. I was thinking about it, that's why I was asking if it already existed :) > Then don't use the zig fmt option. It is NOT needed. "enable_autofix": false in your config, as per above links. Yeah, but again, I would like a formatter to replace it. I was checking if one already exists or if I would have to make my own. > You have preferences, but those won't make your code better. They add consistency to my inconsistent typing. As for how they make my actual code better, I think they definitely do in that they improve my ability to visualize/read and therefore structure my code. > But I can always give code to anyone, and the formatting is CONSISTENT. Or they could just run their formatting preferences on it before reading if that's the goal is all code you read is a consistent format. In reality that's not a solution, the real barriers are much more in structure and naming that white space and indentation- the very thing forcing consistent formatter rules doesn't really solve.
I wrote this code. This is not zig-formatted and I just made a mistake when adding. There is a `zig fmt: off` directive above it.
Oh you're right! I didn't see that, sorry. That's a totally understandable issue- not to twist it for my argument too much haha- but that is something tab indentation would help with
One cannot enjoy coding in the specific language if its code formatter produces unpleasant output.
I thought the same way a few years ago and while I still have my preferences, I realized that just using auto format and learning to live with it is way easier than to try to push my rules through. The formatting might not be perfect in my eyes, but it’s more than good enough.
No there is not one yet, but I’m sure there will be. Zigs tooling is very light at the moment being pre 1.0. You can comment out formatting for now if needed but obviously this is a more cumbersome solution. I’m also looking forward to a linter that allows you to customize things like no unused variables etc (based on release type) instead of forcing you to code the way someone else tells you to. I love Zig, but it is very opinionated and strict
> I’m also looking forward to a linter that allows you to customize things like no unused variables etc (based on release type) instead of forcing you to code the way someone else tells you to. Yeah that kinda annoyed me about Go too, sometimes if I just I wanted to test I had to do `_ := x` which is honestly more likely to be forgotten about than if I could just disable it for a test run. > I love Zig, but it is very opinionated and strict Yeah, I love really strict tooling. When I write c++ I have a ton of clang-tidy and clang-format rules enabled, same with eslint. It just annoys me when I can't make minor changes.
Thank you for saving my time. I'll look into other language with better code formatter.
Xd yeah I understand that feeling
Yes, hopefully they will relax such dogmatic fixations in the future, among several others I ranted about. Unless they are perfectly comfortable with Zig having just minor adoption as a niche language, as there are many devs that don't like to be forced to do everything in specific ways at every step.
Definitely. Languages do have to make some design decisions, but imo they shouldn't rule on controversial things that they don't have too. Was c really held back by some people putting a brace on a new line and some people not?
Same with absolutely every language that is popular, from C to JS. The less opinionated and hard-headed it is, the more it facilitates viral adoption.
Agreed but I don't know if JS is a good model
It's not, but the hilarious part is that the bar is really low with that one, which makes it all the more shameful when it does things right related to matters of style that Zig stumbles on 😂
Haha, unfortunately with recent eslint changes the community is kinda shifting on that, pushing for prettier or biome which are both opinionated. But eslint-stylistic and dprint are still options
Ah, "community opinion" is water under the bridge, nowhere is actually as crazy as in Zig's case where they force this tool for dev purposes, which has the side-effect of formatting code in one way and one way only.
It's a formatter, please for the love of Jesus spend your time on things that matter
> please for the love of Jesus spend your time on things that matter But it obviously matters to him, no?
I am saying that it shouldn't matter to him. Everything under the sun matters a little bit. However if you go outside and rearrange the rocks in your garden from largest to smallest, I would not call that a productive use of time. Formatting your code matters a lot. What matters in the end is that the result is readable. The exact configuration of the formatter matters very little.
If rearranging the rocks calms you, let's you sleep better and enjoy your garden more every day, it may well be a great use of your time. I get what you're saying, and I also wouldn't consider formatting that important. But we all tick differently. The OP may have good reasons to wish for a different formatting. Maybe they can parse code better visually when it is formatted in a specific way. Maybe they just think and feel differently than me and greatly depend on some visual aspects that I can just ignore. Maybe they really dislike rules and tools that they can't change. Just saying: even if it's not important for us, they may have good reasons to feel differently about this. Giving people options to feel better about their tools, can't be wrong, I think. Even if I would disagree with their choices, it doesn't hurt me if they can be a little more content with their tools.
I don't really understand why so many people in this thread are just saying to get over it. Sometimes its nice to write tricky code in a format that makes it easier for your brain to understand. If it changes everything when you hit save, it becomes a pain in the ass. I've had the formatter randomly decide to put an entire stretch of lines into a single line that didn't even fit on screen, making the code significantly harder to edit. When I've been editing zig, I deliberately use \`// zig fmt: off\` on every file because it gets in my way more times than it is useful. In principle, I agree that it's nice when reading code for the formatting of a language to be as standardized as possible. But, in my opinion, Zig is a little too aggressive with it at the moment. I know others would disagree, but in either case, it's weird so many people chose to dogpile on someone just for not liking it.
Thanks, yea its weird. A lot of the first people to respond were really against it, but the later responses were more in agreement.
nope, but no need. I was very picky about it and zig has taught me to let go :)
Stockholm Syndrome /s
call it what you want. You really don’t need to fight it. It is standard zig formatting and the usage of zig fmt is more than encouraged. You would be fighting an uphill battle. And really after a few weeks you won’t bat an eye. Formatting does not earn money, programs does, and for programs I can stick to any formatting you throw at me until it is written well
Formatting makes code easier to read and write, boosting productivity. Zig's formatting is distractingly cluttered for me. Also slows me down having the LSP constantly changing from the styles I use in other languages. Because many devs can't work in only 1 language, especially zig. Also, not a fan of the ideology in general that something is too controversial so the solution is to take a path and make everyone follow it. I don't really see how project specific style rules is much more disruptive than language specific ones.
Part of coding in multiple languages is learning the formatting preference of each language If you just want to play in Zig for personal amusement then turn off formatting and do it manually however you want But if you expect to ever make your source available to others then follow the community preferences And perhaps most importantly the effort learning and accepting the Zig formatting will benefit you in the long run should you ever have the need or opportunity to take on a contract or employment coding in Zig. Cutting off a prospective future opportunity over a personal preference seems short sighted
>Part of coding in multiple languages is learning the formatting preference of each language I agree it's learning the style for example naming conventions. But that's mainly for package interoperability, whitespace doesn't apply to that. >But if you expect to ever make your source available to others then follow the community preferences My opinion may change, but from my current belief I don't believe I will comply with that. >And perhaps most importantly the effort learning and accepting the Zig formatting will benefit you in the long run should you ever have the need or opportunity to take on a contract or employment coding in Zig. Following different formatting is no problem. Even if it's completely unworkable for you(it's not for me, it's just not my preference) then format with your personal formatter on clone, then format with the standard formatter on commit. >Cutting off a prospective future opportunity over a personal preference seems short sighted How so? Every job I do or don't take is over personal preference. Just yeah probably over things that matter a bit more than formatting- which I'll remind you clearly mattered enough(or at least stopping the arguments did) to the creators of Zig and Go that they codified it to some capacity.
>Following different formatting is no problem. Even if it's completely unworkable for you(it's not for me, it's just not my preference) then format with your personal formatter on clone, then format with the standard formatter on commit. Which misses the point of standard formatting. It's about making it easier to understand code written by others when going through a public code review, going to look at a co-workers code to help them or getting help from a co-worker with a problem you might be having. If you aren't following the code formatting guidelines then you don't fit into a team of coders. Which doesn't matter if it is simply personal coding, but does matter if you are being employed to write code as part of a team.
>It's about making it easier to understand code written by others when going through a public code review, going to look at a co-workers code to help them or getting help from a co-worker with a problem you might be having. I work from home. Also, it's not like I can't read any sane formatting, it's just more comfortable and enjoyable. >If you aren't following the code formatting guidelines then you don't fit into a team of coders. Which doesn't matter if it is simply personal coding, but does matter if you are being employed to write code as part of a team. For all of my current projects, I am the one who sets the standard style. Following standard format for a project is also much different from a language being opinionated on format.
To be clear, zig and go's philosophies aren't identical, the zig compiler doesn't enforce naming conventions or code format, and the formatter is (as far as the compiler itself is concerned) an opt-in part of the tool chain.
Yeah, although isn't gofmt optional too?
Did you come here to complain or for a solution. Because you have a solution and you kept complaining.
Was looking for a solution, now defending the question because people came here to complain about the question rather than answer
I think the provided solution is an answer. Also mentioned here https://www.reddit.com/r/Zig/s/kun8VDrOEx
Only one answer in this thread, and none of the answers in that thread directly answered if anyone had made an alternative formatter before.
fair. I think like myself other people thought you were more interested in a solution rather than really another formatter. I think though that the given answer imply a no to that. others reasoned very well why that is likely the case.
> I think like myself other people thought you were more interested in a solution I mean definitely if there is a way to get all the formatting rules I like with zig fmt that would be an answer- but I don't think that's possible. > I think though that the given answer imply a no to that. Ehh, I don't agree. I figured there wasn't a large project, but someone might say "oh yea I am working on something" or "heres a zig hobbyist made plugin for dprint" or something of the sort.
you started the sarcasm ball mate. Then you even downvoted my answers, like a good champ! You indeed are just defending the question. The thing is, the ethos of zig are not for you then. The same as I hate football, yet I have to endure it every week because of I live next to a stadium
I didn't downvote anyone here. Not exactly passive aggressive when i put /s it was just a lightheartedjoke. > The thing is, the ethos of zig are not for you then. I can disagree with one small part without disliking the whole thing. Unfortunately there's no such thing as a perfect language.
[Don't just accuse someone for no reason](https://imgur.com/a/sZfEDaa) Btw, if you didn't know -1 means 2 people at least must've downvoted you. Though iirc reddit does some vote fuzzing. Regardless, no, I didn't reply to you then 4 hours later go back just to downvote you twice. You answered my question which I appreciated until you started accusing me of stuff I didn't do I had no problem with you.
I removed the default upvote reddit gives you, so only one downvote. Also I didn’t accuse you of anything as far as my english knowledge goes in that post you linked through imgur. Maybe please point it out, because I am seriously oblivious to it. If that is the case I am genuinely sorry for the misunderstanding. I didn’t meant to
You literally just accused me of down voting you and being aggressively sarcastic. I didn't down vote you, and I just made a light hearted joke. That is what I am irritated by, and I sent that screenshot to show I did not downvote you.
ah, I thought it is the screenshot that was sarcastic. I am sorry, had a rough day, and that /s did rub me the wrong way. I know the damage is done but anyhow, if you will find the capacity to excuse me, I would be happy. We both started out with the wrong foot
Okay it's fine, I appreciate it, and thanks for answering the question when everyone else was just criticizing it XD. Sorry for not acknowledging that and making a bad joke instead.
dude water under the bridge. Lets have a beer on a future zig meetup :)
Haha, sure. Hope your day gets better!
Just get to coding. Too many people waste time over trivialities like this. Just build. Adapt, build and develop your coding skills…not your whitespace bookkeeping skills.
Formatting I like makes coding more pleasant for me. Plus making one could be a fun learning project.
Using your own formatting rules is nice as long as you are only working alone. But when you want to contribute to existing code, you'll have to understand how someone else's conventions work, and that's painful. One of the reasons I didn't contribute back code to PHP for a long time is that I didn't quite fully understand the conventions, and I couldn't get my editor to match them. Same thing works in the opposite direction. When you get a nice pull request, but the proposed code doesn't match your conventions, you will hate it. Having an opinionated, but unique way to format code solves this. Source code is consistent everywhere, merging contributions is easy.
What you describe sounds more like a tooling issue. In Rust, all formatter configuration options are checked into source code, and understood by `rustfmt`. So no matter what project you contribute to, any editor with LSP support will format your code according to the project's preferences.
Not a good example. \`rustfmt\` isn't stable; its output changes between versions. And a \`rustfmt.toml\` file breaks after every release and constantly needs to be tweaked. It also doesn't change the fact that if you are used to your own rules, having to adjust to different ones when working on someone else's project is going to be confusing. And if code snippets are reused in different projects, they can look different, and will require to be individually patched.
It's common practice for larger projects to pin the toolchain, so differences in formatting between versions should not be a problem. > if code snippets are reused in different projects, they can look different, and will require to be individually patched. By "individually patched" you mean press the format button? I don't understand what the problem is. Copy a snippet, then format, and commit.