Me reading this article: yup, yup, yup, yup, wait a minute!
This part feels a bit snuck in, in a "leading and pacing" kind of way: All the other points are long-established no brainers, but this one is still controversially discussed and I'd say - in the general form it's presented here - wrong.
The author is still right that it's wrong to categorically dismiss AI tools when coding. But you'd have to apply a lot more caution to this point than to the others.
I hope sneaking this in wasn't the real motivation of the article.
Example
somethingService = ...
somethingService = somethingService.Do()
Weird. You almost never need to do string eval in python, and whenever there is something where you think you need eval there is a better and safer way to achieve the same result.
Also, I was bending my brain but I couldn’t really figure out what this eval was for until I wrote out some scratch code myself to figure it out.
Turns out this 5 lines or so was constructing a string to do dict lookup and then evalling that. So say you have a dict d = {‘foo’: ‘bar’} and you have a variable i=foo and want to look up d[i], instead of just doing that it was doing something like
eval(‘d[‘+i+’]’)
So I rejected the change and they came back with “but we’ve always done it that way”. I grep the codebase and yes. There were about 200+ uses of eval, all of which were constructing a string to look something up in a dictionary and then evaling the result. Some person who clearly didn’t program in python had found this twisted way to look things up in a dictionary and then this team had dutifully copied and pasted it throughout the codebase.
[1] ie I wasn’t there from the start of the project
For instance: An e-commerce API that used JSON. Not only did the spec. tell them to use integers with pence for prices, but it explicitly called out that it MUST NOT use floating points with pounds. Sure enough, they implemented it as floating point pounds. So we asked them to fix this.
The underlying datatype in the database was pounds in a decimal type. You would think that they would multiply this by 100 and call it a day. What they actually did was: a) render it as a string, b) strip the period character, and c) parse the resulting string as an integer. They didn’t test this properly before deploying, which resulted in us charging the correct price for things that cost £xxx.x5 but undercharging by a factor of ten for things that cost £xxx.x0 and undercharging by a factor of a hundred for things that cost £xxx.00.
That's code review's worst! Happened to me many times.
The strings here included user input too. Worse still, the situation was the company was offering a b2b service and the string didn’t just come from user input by an employee of the company they came from arbitrary customers of the customers of the company.
image.size
ndarray.shape
Trick question of course, it's (height, width, channels) for numpy. numpy is fairly well known though and sort of gets away with it, but when your never-seen-before internal company starts doing this, well...
Really I think what makes languages with manual memory management and limited built in types like C nice is it forces people to really think about the types and interfaces they're writing instead of just hacking unmaintainable code at 20 lines an hour.
Just trace back the dict to it's origin, through all the places it can be modified, and you know what is (or could be) inside...
/s
So, stable packages?