If your code files don't contain more lines of comments than lines of actual code, then you're doing it wrong. (For Python, docstrings count as comments)
And your comments shouldn't say what each line of code is doing. If you can code, then you can already tell what each line is doing by just reading the code. The comments should explain WHY it's being done this way, or HOW it's being done, or highlight some pitfalls that might snare a future developer, and generally just give some higher level context to a line or block of code.
Oh fuck I hate encountering this level of commenting. If it’s complicated, you should have a design doc. Source code is not where you write your dissertation. Simple explanations are good, especially since the code could be updated while the comment is likely to remain unchanged. Long expositions are usually the result of bad coding or improperly allocated design.
Absolutely agreed. If your code line by line isn’t clear, then the code is the problem.
Commenting before a block of code (a function / algorithm or whatever) explaining what it is meant to do, absolutely that’s great though, saves time when revisiting.
And that one single line that makes zero FUCKING SENSE AND YOU SPENT 5 DAYS TRYING TO FIX IT!!! That definitely needs a comment so the next idiot (aka you in 6 months) doesn’t think “what useless shit is this? Let’s delete this!”.
Comments are for revision control systems. We have a strictly no comments in code policy because comments too often end up being wrong or misleading throwing everyone believing in them for a wild ride. The only thing that is worse than bad code is bad comments.
When you read sensible and thorough commit messages you generally have the notion that whatever it says was probably true at the time of the commit, whereas when you read comments in code it can still be correct or just plain utterly wrong.
@nthcdr this assumes that people write sensible and thorough commit messages, instead of brief five-word ones or, say, song lyrics. Both of which I've seen.
I at least try, except maybe for the other day where my commit message consisted entirely of an exasperated "why", followed by a revert.
That being said, every commit message where I work is required to contain a ticket number (and the server will reject the push if you don't) so at least there's that for context.
Yes there need to be some assumption that your co-workers write reasonable commit message even if they have their lapses now and then.
Another problem with comments in code is that they tend to be short because nobody likes to read code interspersed by walls of prose. But many times if something really needs explaining you also need a little more room doing it. Thus when committing in code people tend to gloss over important detail.
Then of course there is literal programming. The other end of the spectrum, but then we're talking code in documentation not comments in code.
I left the company, worked at other places in other languages, the company restructured, moved to India and back, got new premises, headhunted me because someone remembered that I wrote this particular system (serial port controller for certain industrial machinery). When revisiting code that I wrote 15 years ago, I was glad that my comments explained what I was doing, and why, and how, because all the other documentation was long gone. Don’t imagine that the original design documentation will still exist when you come back to it.
It also greatly improved readability of the language. Since switching to the standard of using 4-space tabs, I’ve not had any problems except when dredging up someone’s old Python 2 code.
You can create some really ugly code in spite of the forced indentation in python. Indentation does not really help here at all. In all languages you can correctly or incorrectly format things. A code formatter strictly applying a coding standard helps far more here than indents vs bracers. Take a look at black it takes the pep8 standards and adds more strict things on top making code look a lot more consistent and thus makes it easier to read.
And all formatters will indent code consistently, so having it as part of the language parser does not really help improve readability at all. And even without a formatter everyone I know will still correctly indent their code no matter the language used. But sometimes forcing new lines to have a meaning does make things worst - just look at pythons lambdas which have to be a single line.
Indentations does not really help readability that much in case of really, really, long code, and in some cases, a code can execute without with unexpected result because of one single indentation being off. Both of these why I like things like curly braces/brackets and terminators like endif/fi/done/end/etc. But, at the end of the day, if there’s a readability problem, then that’s a sign that the code needs to be reworked on.
Oh I think indentation helps a ton with readability. Even for bad, long or otherwise hard to read code - it would be way, way worst with no or wrong indentation. Correct indentation helps a lot. It is not the only thing that can be done to improve readability but it is the first and simplest fix you can apply to a code base. So a language enforcing it with syntax does not matter when even basic text editors can correctly and automatically indent your code.
I didn’t say it doesn’t help. But, it alone does not really help for bad and long code, but you are correct in that it would be worse with the wrong indentation. Like you pointed out, the program could do the wrong thing if there is a wrong indentation where indentation matters which is one of my issue with something like Python. And languages with explicit exit scope tend to not have that issue while adding to the benefit of making longer code readable. Where white-space sensitive languages really shine on in my opinion are small codes, and that’s where I think of using Python.
Braces too can be wrong. But, one is less likely to get it wrong. Modern editors often allows one to highlight matching braces immediately after selection, and rainbow braces(if available) makes it clear on the nest level.
Just copy some code over into a not properly configured vim.
People seem to forget that not everything is a fully configured development environment working locally on your laptop which attempts to fix the issues introduced by that design decision.
Write the whole thing, and only then, scrap it and rewrite it. This way you actually have a good understanding of the entire implementation when you are rewriting. When I refractor while writing my draft I will slow myself down and trip over myself, I’ll be way more likely to rewrite something I’ve already rewritten.
Sure there is a limit to the size of projects this can work for, but even for massive projects they can still be broken into decently sized chunks. I’m just advocating for not rewriting function A as soon as you finish function B.
Write the whole thing, and only then, scrap it and rewrite it.
Exactly. And that’s the part a lot of folks don’t understand about writing tests. If we’re not sure an interface will survive into the rewrite, it probably doesn’t belong in the test suite.
And the rewrite can be very fast, if we tested the right things.
SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.
90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.
Unless your web site needs to work offline (it probably doesn’t), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don’t need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).
I do a lot of PHP, so naturally my small projects are PHP. I use a framework called Laravel, and while it is possible to use SPAs or other kinds of shit, I usually choose pure SS rendering with a little bit of VueJS to make some parts reactive. Other than that, it is usually, just pure HTML forms for submitting data. And it works really well.
Yeah yeah, they push the Livewire shit, which I absolutely hate and think is a bad idea, but nobody is forcing me, so that’s nice.
I loathe JavaScript heavy websites, especially when used for forms. Don’t break autofill and copy/paste. And don’t complain about the format just because I pasted! Seriously, why is pasting text in the correct format triggering some JavaScript framework? It all seriously gets to me.
With that said, I really like Hotwire. HTML over the wire is bliss. Stimulus is perfect for sprinkling non-invasive JavaScript throughout an application.
Preferring server side rendering is an interesting topic
Client side renderering is currently the preference because the company gets to offload the compute costs of their servers onto the clients’ devices
As long as every website has a profit motive, even if it’s just a single person trying to save some money on their AWS bills, server side rendering will never become the norm
The difference between generating JSON and generating HTML is minimal for the server, doesn’t seem to me like server side rendered sites have significantly higher server compute costs. Also generally for SPAs, the server has to replicate whatever flow is happening on the client anyway to keep state in line (since the client can’t be trusted)
The difference between generating JSON and generating HTML is minimal for the server
That should be true, but have you looked the HTML of any “modern” site? Dozens of nested elements, each tagged with multiple lines of attributes. Generating that is probably 10x the cost of generating the JSON.
Plus, with server side rendering you also have to recompute the HTML for the entire site, which often contains a whole bunch of non-trivial queries as well.
Plus, with server side rendering you also have to recompute the HTML for the entire site, which often means re-computing a whole bunch of non-trivial queries as well.
This is actually why I really like HTMX, you load a page once, then make AJAX requests that return html which you can use to replace or add to the DOM. It provides an interactive front end where the backend provides full rendered html partials. Simplifies the entire application by keeping logic and state only on the server, which means you never have to worry about synchronizing front-end and backed state.
I’m still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.
I’m thinking more along the line of ubiquitous offline first PWAs. Imagine google doc running offline in a browser and being able to edit local docs directly. I guess secure file system access is one of the major road blocks, though I’m not sure of the challenges associated with coming up with a standard for this.
Actual hot take, Blazor is awesome, it is like Microsoft looked into ASP.NET Forms, ASP.NET MVC and Razor, and bundled it to one quick framework to do simple WebApps.
Counter hot take, I do actually like Blazor but it has limitations due to how immature web assembly still is. It also does not solve the problem of being a big complex platform that isn’t needed for small simple apps. Of the half dozen projects I’ve written in Blazor, I’d personally re-write 3 or so in just Razor Pages with Htmx.
You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren’t sure where data sources come from and can’t write a one-line comment.
Dynamic typing makes you fast, it’s empowering. Try it and quit being so scared.
No matter how many unit tests or comments you write, it’s impossible to statically “prove” type correctness in a dynamically typed language - and it will eventually blow up in your face when you have to refactor. There’s a reason for the adage “testing can’t prove the absence of bugs.”
People like static typing because it offers strong guarantees and eliminates entire classes of bullshit bugs, not because they’re “weak minded.”
Incorrect. Static typing can prove many things, depending on the quality of the type system.
At the very least, it proves that your data is organized, stored, passed around and used in a logically valid and consistent manner. Make that proof impossible, and the compiler complains. (And with good reason - it doesn’t matter how good your program logic is if you’re feeding it bad data. Garbage in, garbage - or a runtime error - out.)
In a dynamically typed language, your program logic still implicitly depends on that proof holding - it’s just that you, the fallible human, has to make sure everything checks out. Python added type hints for precisely this reason.
Additionally, with more advanced static type systems, it becomes possible to issue guarantees beyond simple type safety. Patterns like typestate (found in TS, Haskell and Rust, off the top of my head) can be used to make illegal states unrepresentable at compile time. Try to write to a closed file or make an invalid state machine transition? The compiler will see it and say no.
It just creates bugs and crashes.
In what universe are runtime errors turned compile-time errors a source of bugs and crashes? A statically-typed program won’t blow up in production because some poor intern wasn’t able to keep the implicit type bounds of every single function parameter in his head.
There’s some math & CS papers you should read, Gödel’s incompleteness theorem, Turing’s halting problem. YOU CANNOT prove your way out of logic errors. You cannot make a universal type system. All you’re doing is wasting time with false confidence.
I agree, strong typing is for weak minds. I work with a weak mind so I want strong typing.
There’s no difference in speed between typing disciplines. In point of fact, there cannot be. You must know the structure of your data to program against it. Whether you write it down explicitly or implicitly changes nothing but the location you wrote it down.
It is cool to get things done quickly (and dirty), I will give it that.
But if you need to revisit it later or have someone else take it over / expand on it this opens up the gates of hell for errors and will fall on your feet. What time you gained by getting it done will be lost, and then some, and some more over the years to come.
Source: couple of years with Python and such problems. May not be the only one with that experience, and that may be the reason why they introduced type hints in 3.8.
I’m not any faster in languages without static types. It’s the opposite, I’m fastest when I can write accurate type hints, since it makes the editor experience much better.
All my career. They can’t program, they have no valid opinion about programming, as long as we finish the user stories. Which is several times faster in a nice dynamic language than a bondage language.
Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It’s like the assembly of type systems, except it makes your program slower instead of faster.
Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it.
What happens when you coerce a string to a date-and-time but it’s not valid?
Where I’m from (Rust), error handling is very strict and very explicit, and that’s how it should be. It forces you to properly handle everything that can potentially go wrong, instead of just crashing and looking like a fool.
When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing.
If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid.
By “user” I mean the person who is using the application.
Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don’t know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes.
I’m not convinced that “strong pairing” is the best way to pair but even people who rail against agile ideology tell you that you’re pairing wrong if you don’t follow it precisely.
We’v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams
Omfg yes! Have nothing to add, but an upvote was not enough to express my hate for gitflow. So fucking stupid. And you’ll show stats from Jez Humble etc about trunk based, and my boss was still “eh not convinced”
Github flow has the same issues, in practice. Branching is the root cause, not the kind of branching. Even anonymous branches. Its the frequency of integration that matters.
Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline.
Got asked about this twice so I’m cut/pasting my answer, but happy to discuss further
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
what data? just curios because there are so many ways to do PRs properly… like for everything, if it’s done badly better not do it. does not mean it is inherently bad
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?
You must trust your team’s abilities more than I trust my own. How often does your team merge bugs into main? We use CI primarily for running the full test suite, including integration tests and e2e tests that would be very difficult to run locally due to them using specific credentials to access testing resources.
I trust my team. I don’t trust my or their ability to write and merge perfect code each time. I’m not sure how we’d fix that problem aside from becoming programming gods.
My point is, having PRs desn’t result in perfect code either. They might help sometimes, maybe 10% of the time if I’m being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions.
The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code.
Its IDE is based on Scintilla. And it is very fast, even on an ancient PC it runs. It is specific for the programming language.
And here some advantages it has compared to a simple text editor:
Autocomplete of all functions and many API functions of the OS
Hints about parameters
F1 Help for all functions by just placing the cursor on them
Jumping to errors in the code
Automatic backups of all the progress of your codes, no problem to backtrace even if you forgot to save or commit.
Manage Projects (Groups of source codes and different targets)
Well integrated debugger
I agree with you in many points. Most other IDEs I am forced to work with are horribly slow. Especially those which rely on electron. Sometimes they lack features every basic editor has by now.
Jetbrains IDEs do a lot of indexing and caching so that operations that normally take a bit are faster. Full text search, find usages, identifying interface usage in duck types, etc.
But the killer feature for me is the refactoring tools. Changing a function signature, extracting an interface, moving code to new files or packages, etc. I pair with folks who use VS Code and its a bit tedious watching them use find and replace for renaming things.
I’ve never been able to benefit from an IDE in a way that make up for how much slower and more bloated they are.
That does sound legit if you have resource limitations. Thankfully I’ve always worked for corporations that hand out MacBook Pros like candy. Normal day for me is having two Jetbrains IDEs open with Chrome, Slack, Zoom, and a dozen containers. Still runs smooth.
In my experience it HEAVILY depends on the language you’re using. Nothing beats Intellij for Java or Kotlin, but Rust and Go feel at home in any editor.
I know that LSPs and DAPs somewhat take care of these, but the following are often easier in IDEs:
Refactorings, including really smart language specific ones
Support for fancy frameworks. For example, Intellij can analyse all annotations for Dependency Injection or Spring stuff, and will then tell you exactly how everything connects on a higher “framework” level. Arguably, this is a solution to a problem Enterprise Java created
Debugging is easier
In general, stuff works “well enough” out of the box. As a fan of Neovim, I’ve definitely been frustrated a lot the first time I had to set something up
Fancy integrations, for example linking frontend code calling backend code directly, or an entire little Database Manager builtin, with magic SQL code completion
Python development without PyCharm (or IntelliJ) and the IdeaVim plugin is unbearable. List usages is a game changer. Don’t care much for anything else.
Yeah, well, that’s just Python for you. List usages is now an LSP feature for most languages, so will work with “lesser” editors too.
All that being said, I use Intellij with Java daily, so I can see where you’re coming from. But for example Rust or Go works wonderfully with Neovim (or VSCode).
Yup. Emacs, here, but same thing. Never used PyCharm or any other Python-capable IDE, and I’ve been coding large python projects for the same company for almost a decade.
I am bad at coding and it is a skill that I do not think everyone can achieve to a professional level, thus telling people to “learn to code” is similar to telling them to “just hustle”, “hit the bricks and hand out resumes”, and other flippant stories that mean you stop having to think about poverty.
That said, I do believe the narrative actually was true for some people at some time. Maybe in the 90s and early 2000s if you were able to cobble together a computer from bits your university was throwing out and you had internet access, you could punch well above your weight. But that certainly was never true for everyone.
(I like to be optimistic about people’s ability to learn things, mostly hampered by access, time, and lack of interest, but I went to a boilermaker’s course recently to learn how to weld and none of those kids were going to learn how to code even if they were interested, whatever their other skills were.)
I sometimes feel like the last person that managed to land a decent tech job without an undergraduate degree, but a good part of that was being able to play a normal, likeable person in the interview.
I think what you say might be true for any field that’s new enough. There’s high demand for labourers, very little skill around, and a low barrier for an autodidact to pick up the basics and outshine the competition.
I started my career as C# dev and thought highly of Java because it’s what C# is ripping off of. Then I actually tried writing Java and had a new found appreciation for C#. This was over 10 years ago though.
Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.
Don’t even worry about what your first language is. The CS snobs used to say BASIC causes brain damage, but that was wrong. JavaScript is fine, C# is fine … as long as you don’t stop there.
Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”.
Yeah. I’ve written in six or so different languages and am using Go now for the first time. Even then, I’m trying to be optimistic and acknowledge things are just different or annoying for me. It doesn’t mean anything is wrong with the language.
Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”…The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.
Well i mean… that’s kinda what “unintuitive” means. Intuitive, i.e. natural/obvious/without effort. Having to gain familiarity sorta literally means it’s not that, thus unintuitive.
I dont disagree with your sentiment, but these people are using the correct term. For example, python len(object) instead of obj.len() trips me up to this day because 99% of the time i think [thing] -> [action], and most language constructs encourage that. If I still regularly type an object name, and then have to scroll the cursor back over and type “len(”, i cant possibly be using my intuition. It’s not the language’s “fault” - because it’s not really “wrong” - but it is unintuitive.
If you only know C and you’re looking at Python, the absence of curly braces on code blocks is temporarily unfamiliar to you.
But if you only know Python and you’re looking at C, the fact that indentation doesn’t matter is temporarily unfamiliar to you.
Once you learn the new language, it’s not unfamiliar to you anymore.
“Unintuitive” often suggests that there’s something wrong with the language in a global sense, just because it doesn’t look like the last one you used.
“Unintuitive” often suggests that there’s something wrong with the language in a global sense
I mean only if you consider “Intuition” to be some monolithic, static thing that’s also identical for everyone. Everyone has their own intuition, and their intuition changes over time. Intuition is akin to an opinion - it’s built up based on your own past experiences.
just because it doesn’t look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.
I don’t think it’s that deep. All people mean when they say it is that “[thing] defied my expectation/prior experience”. It’s like saying “sea food tastes bad”. There’s an implicit “to me” at the end, it’s obvious i’m not saying “sea food factually tastes bad, and anyone who says they like it is wrong or lying”.
You could say that about anything. Of course you have to learn something the first time and it’s “unintuitive” then. Intuition is literally an expectation based on prior experience.
Intuitive patterns exist in programming languages. For example, most conditionals are denoted with “if”, “else”, and “while”. You would find it intuitive if a new programming language adhered to that. You’d find it unintuitive if the conditionals were denoted with “dnwwkcoeo”, “wowpekg cneo”, and “coebemal”.
But there are languages that require varying degrees of effort to become natural. Something like Malbolge will pretty much neber be natural while something like Python can become natural to you in a few days.
This is very true! Languages being unintuitive also becomes less of an issue the more languages you look into. There will be many concepts that multiple languages have since ultimately they are all trying to do similar things and the more you learn the more you will recognize making it easier to get into even more languages.
ZZT-OOP is fun to work with though, definitely not meant for doing anything more complex than light gameplay, and yet people have done ridiculous things with it.
Though I personally did most of my coding in that vein in MegaZeux with their Robotic language, which is basically ZZT-OOP++.
Idk, I don’t see a problem with saying a new language is unintuitive. For example, in js I still consider the horrible type coercion and the “fix” with the triple-equals very unintuitive indeed. On the flip side, when learning C# I found the multiple ways of making comparisons to be pretty intuitive, and not footguns.
Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.
This is wise advice for ANY domain of knowledge.
Lotta people get a little fragment of knowledge on something, then shut down their brain and stop accepting new input. But life is change, and to be able to change and learn new things you need to keep your mind open. Being able to relax on having opinions and keep learning and moving along is very important.
Add comment