[deleted]
Formatting code should be unnecessary
431–440 of 484 posts
Re: Formatting code should be unnecessary
#432Earlier quoted context omitted.
> I've never understood why people care so much about the linter settings. Source code formatting programs are not the same as lint[0] programs. The former rewrites source code files such that the output is conformant with a set of layout rules without altering existing logic. The latter is a category of idempotent source code analysis programs typically used to identify potential implementation errors within otherwi…
Thank you! I am almost going out of my mind reading this ~200 comment thread with everyone just casually saying "linter" when they mean "formatter". Do people really not distinguish between these two very different programs?
I guess the line might feel fuzzy to some people, since nowadays many tools bundle both linting and formatting. And with modern IDE integrations, you might not even run them explicitly — the editor just does both automatically in one go.
Re: Formatting code should be unnecessary
#433Earlier quoted context omitted.
100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for…
Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.
IMO, implicit string concatenation is a bug, not a feature.
I once made a stupid mistake of having a list of directories to delete:
directories_to_delete = (
"/some/dir"
"/some/other/dir"
)
for dir in directories_to_delete:
shutil.rmtree(dir)
I essentially did an `rm -rf /` because of the implicit concatenation.
Re: Formatting code should be unnecessary
#434I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.
> just make a choice, run the linter automatically and be done with it.
Most people probably do this. These types of discussions (probably) come up when someone else made the choice and other people also need to adhere to this choice. This is important for teams, but sometimes big egos don't want these choices made for them.
Re: Formatting code should be unnecessary
#435Earlier quoted context omitted.
> In actual Common Lisp development, code is stored in text files and edited and diffed as text in source controlled repositories. That's true, but there is a very big difference between S-expressions stored as text and other programming languages stored as text because there is a standard representation of S-expressions as text, and Common Lisp provides functions that implement that standard in both directions (READ…
Its interesting that despite the utility of S-Expressions, as mentioned, semantic diff, for example, of CL code is uncommon. By that I mean highlighting the diff between these: (dolist (i l) (print (car i))) (dolist (i l) (print (cdr i))) With the diff highlighting the `car` changed to `cdr` rather than just the raw lines being changed. I'm pretty sure this exists, but it's uncommon (at least to me its uncommon).
It is uncommon because it turns out that text diff is good enough 99% of the time, especially if you follow normal formatting and indentation conventions.
Also, structural diff is actually a very hard problem.
Re: Formatting code should be unnecessary
#436I like that. We should have something like this for python. Black is great, but maybe it's just me since it aligns with how I like the code formatted. Would there be any downsides for python (or git ?) to define a standard way of formatting to save a valid file, and all the formatting necessary to read a file happens in the IDE showing the file ? That would very much fit with python ethos 'There should be one-- and p…
I think the downside would mainly be complexity. As soon as you do that, you have to develop what that intermediate representation is and how it gets stored. But moreover, you'd need to develop workarounds for the fact that all external code infrastructure (version control, editors, command line tools) is built for text. I can't see a crazy huge downside from a python point of view, but seems like a much bigger upsid…
I was thinking just plain python - let's say Black formatted code is the default and we commit only that. Then on the visualization side, the IDE can format it for whatever we want.
Actually, this could be a really easy feature for the IDE and could work already easily.
Re: Formatting code should be unnecessary
#437Earlier quoted context omitted.
The complexity of a parser is orders of magnitude higher than that of an AST schema. I'm also not saying we can have all these good things, but they are not free, and the costs are more spread out and thus less obviously noticeable than the ones projectional code imposes.
Are you talking about runtime complexity or programming-time complexity? If the runtime, then I bet almost no one will notice, especially if the appropriate caching is used. If the programming-time - sure, but it's not like you can avoid parsers altogether. If the parsers are not in the tools, they must be in IDE. Factor out that parsing logic, and make it a library all the tools can use (or a one-shot LSP server if…
I meant programming-time, but runtime is also a good point.
Cross-language libraries don't seem to be super common for this. The recovering-sense-from-text tools I named all use different parsers in their respective languages.
Again, reading (and yes, technically that's also parsing) from an AST from a data-exchange formatted file is mags simpler. And for parsing these schemes there are battle-tested cross-language solutions, e.g. protobuf.
Re: Formatting code should be unnecessary
#438Earlier quoted context omitted.
The problem is when 2 people with same level of enthusiasm for linter rules but opposing views collide. If there’s nothing more impactful you could be solving and spending energy and time on than arguing those linter rules, then it’s time to question where the project is at and where is it going. And if there is something more important, then instead of of micro-optimizing the rules when there is strong disagreement…
I guess that's one reason why opinionated tools like prettier or gofmt are popular. They made all the choices for you, they don't have configurable knobs, so you just learn to live with it.
FWIW, there are formatting decisions that gofmt doesn't make for you, so it's not as simple as just using gofmt.
Re: Formatting code should be unnecessary
#439I wrote an article saturday on visual programming which is very related to this, but my thinking is the opposite of this article. Raw text is amazing at smaller scales. The ability to apply a bunch of intermediate incorrect transformations to reach a valid destination is invaluable (like doing a bunch of hacky find/replace). Projectional editors like JetBrains MPS have tons of disadvantages vs text, and the few advan…
My singular problem with visual programming is simply the amount of detail necessary in modern programming. Code is flat out complicated, with lots and lots and lots of steps, each with perhaps even more detail. And it's hard to do that efficiently with visual editors. Imagine a display with instead of thousands of lines of code, you have thousands of symbols. Or, the visual editors break things down in to components…
Indeed, putting related code together in the same source file is one of the ways we cope with complexity.
Though it too breaks down, because the relations between various bits of code may be so complex that there's no good way to "linearize" them.
And you should be documenting your code, but documentation comments take up space on the screen since they are linearly arranged in the same file, so you see less functions at a time.
Imagine as an alternative that the documentation was presented on a side view of the functions, like how you can open two files side by side in VSCode. Then you'd be able to see many more functions at the same time.
If you have any unit tests then it would be great if you could see them (and run them) while editing the function. In Rust you can put tests in the same file as the function (very nice) but usually on a submodule at the bottom of the file rather than near the function itself. Again, the problem of trying to linearize everything in a single file.
The issue with visual programming tools is that they don't put any thought into this. On how they could actually help get you the information you want to see. Instead they focus on letting you make cute drawings.
It's a UX problem, we should be able to do better than text files, even if what we end up editing is still text (because of all the advantages it has).