Think about when you were a beginner at programming, when you were just starting out. Now if your main tool as a beginning programmer was a plain-old text editor like mine was, you probably enjoyed and might still appreciate a more hands-on approach to learning, where you know what’s happening under the hood. Maybe you later on graduated to using an IDE because you either had to (like with Android Studio), or because you found it saved time.
But if you started out learning with an IDE, there’s a decent chance that you used helpful IDE “features” like drag-and-drop, and later realized you had to learn to write raw XML to design layouts anyway.
Obviously this isn’t true for everyone so I don’t mean to generalize, but my point was to illustrate the issue I have with drag-and-drop: it’s a level of abstraction no programmer should strive for.
Generally speaking, I’d say the more abstracted things are, the better. No one writes web apps in assembly. But using drag-and-drop and ignoring generated code completely is generally a bad idea, at least in standard Android development. The drag-and-drop functionality in Android Studio isn’t mean to completely replace raw XML coding (that’s why you always have the option to switch to text), it’s meant to reduce the amount of typing you’d otherwise need to do to get views and view groups. It’s essentially like the “add new activity” wizard: it provides you with stub code that you’re supposed to edit to suit your particular needs, saving the need to write everything from scratch.
When you drag and drop things and ignore the code that gets generated, you’re relying on the IDE to format your code according to your coding conventions (you have those, right?) and any optimizations you may need to do, depending on how complex your layouts are. That, or you just don’t care about any of that stuff, which is Bad Practice™.
Don’t get me wrong, I have nothing against using drag-and-drop for the purpose it is supposed to serve, i.e. to save time. I see the value in dragging and dropping views or widgets and then customizing the code. Point is, you should be aware of what the code does, and relying solely on drag-and-drop cripples this awareness.
Now this isn’t true 100% of the time. There are cases where your IDE generates code that you’re not expected to look at. The most obvious example would be auto-generated code that’s temporary and regenerated on every build (e.g. files in /build and /app/build directories in Android Studio). Another example could be Django’s migrations, but those are still part of your project and you should be ready to get your hands dirty with them if needed.
As a general rule of thumb, anything that you don’t exclude from your version control system should be considered code that you should be willing to work on, and if that’s not the case, you need to ask yourself why.