As the rambling title would suggest, I fully expect this to be a very rambling and undefined post.
I don’t like auto-complete much, and it’s not only because I find it a hinderance more often that not, although that might’ve driven me to justify my dislike with the following argument…
I think it adds a layer of abstraction that encourages bad practice. For
example, if you’re defining an enumeration one of your primary goals should be
consise and clear names – this is after all the strength of an enum – the
name of a given member should be immediately obvious based on the defined
naming convention.
But when you have an auto-complete dropdown listing all the available options you’re no longer concerned with whether the consistancy and justification of the names – you’re menu hunting for the one that looks best.
I’d argue this extends to encouraging bad API design (not that I can claim to
be good at this) – have you ever wanted to find the string method that
splits on a delimiter and found yourself scrolling through the auto-complete
suggestions? I’m not saying that using auto-complete makes you a bad programmer
– not at all – what I’m trying to say is that if you find yourself relying on
it to do more than auto-complete, then there’s probably a more fundamental
problem afoot.
In fact I’ve been wondering about an auto-complete that does just that – press you keybind of choice to finish the next word. You might even be able to get away with more – I’ve found the Tabnine project incredibly useful of automating repetitive aspects like writing typeguards in TypeScript to a common, but repetitive style guide, e.g.
if (!thing) return false
if (typeof thing !== 'object') return false
if (typeof thing.str !== 'string') return false
if (typeof thing.num !== 'number') return false
At this point if I wanted to add a check for a property thing.obj, I would
probably type if (type, hit auto-complete to finish the line and come back
to ammend the type were checking against (this isn’t a theoritical case for
once, I’ve actually programmed like this at work and it worked quite well).
Anyway the reason I’m writing any of this is because I’ve found myself frustrated with a percieved difficulty updating behaviour of an application writen using a GUI RAD/WYSWIG-style frontend. I think part of the reason this application seems so massive and convuleted is because in the past I’ve exclusively interacted with it via menus (the way the system is intended to be used), as a result the actual c# backend code that gets generated does not feel intuitive to extend whatsoever.
A part of the problem is presumably to do with a difference in terminology between the developer and client – in this case I am the client and the GUI & code-generation application developers are the developer. There’s some crappy buisiness term for this I’m sure but I think it’s a good example of how using common terminology across your client-facing and developer-facing interfaces.
So I’ve been working with a code-generating GUI using RAD-ing application at work – for quite a while now actually. I don’t love it – in fact most of the time I dread it – but it’s undeniably good at what it’s doing (most of the time). As suggested above there are cases where extra functionality is needed and I get my hair caught in the machinery that is the code-generation side and these are the worst cases.
I’ve developed a couple of applications using it and it really excels at beating MS access… the problem is when the requirements outgrow it (I imagine this is exactly the predicament that Access and Excel developers before me ran into).
So I when I set up a project I commit the ‘meta’ files the frontend generates (some JSON files), and any manually changed c# backend code – leaving the code generation part to build off the JSON files. This makes a lot of sense as the application overwrites all the other artifacts anyhow and saves a lot of lines in commits.
But what happens when this code-generation application goes poof – unfortunately it’s not backed by Microsoft like Access and when it goes poof it’ll really go poof. I don’t expect this to happen for a while, but what I can see happening is my boss not wanting to renew the license for the code-generator, but me needing to provide maintenence upgrades to existing, shipped projects. Oops.
So maybe it is worthwhile commiting the artifacts. In fact maybe it’s worth dropping the generation aspect completely after I get the basis done – it’s regularly more of a detriment in late-stage development as you end up updating multiple dropdowns because there’s no find-and-replace.
I don’t know – another advantage of commiting artifacts is obviously in ease of access for other developers (although creating potential headaches when merging upstream). If you’re using something like GitHub anyway it actually makes a lot of sense to commit your transpiled typescript -> javascript (for example), so that it’s available immediately via GitHub pages.
Did any of that make sense? Did it have any value? Probably not… I think I’m going to write an application that generates an RSS feed for this blog, and I’m not sure if I’m going to committing the source code as well as the generated feed, so I may be about to prove myself a fool :^)