Is there an ideal code editor usage percentage?
No, there is not.
Do productive software developers/coders spend around 70-80% of their work time in code editors?
Not in general, but some likely will match that number at least sometimes.
Is it a correct basis to calculate the work-time or mark their attendance on the
basis of above mentioned factors?
Why is there no ideal code editor usage percentage?
- everyone is different
- everyone's work pile is different
- everyone's work pile contains different items from day to day
- everyone's environment is different
For 1) I sometimes love to work with a black board to come up with algorithms. That works for me nicely. Some other colleagues rather try out coding prototypes until one works. One coder looks at the DB via the code editor the other uses a command line db client. -> Differences in average code editor usage.
For 2) A senior developer might do more high level design and a junior more small tasks that are straightforward. One developer might do some DevOps task and write scripts in a text editor or coordinate software rollouts with another department. → differences in editor usage.
For 3) Monday everyone might be coding at the next release version, when suddenly during the night, servers with the old version crash due to a memory bug. Next day everyone jumps onto the log files, looks through database entries, hooks up debuggers or drives to the data centre to take a look at the cabling (or calls them). → Huge variation in code editor usage.
For 4) One colleague might work in a home office, and the others in the real office. The real office people can talk without switching the context on their PC, and the home office colleague needs to spin up a messenger. Or one colleague might have two monitors while another has one in his home office. The two-monitor person can leave the requirements open on his second screen, and the one monitor person needs to constantly switch. -> different code editor usage.
Bottom line: Unless you have a very strict assembly line development process, where every coder is supposed to work the same way, has the same kind of tasks every day and has the same setup and tools (without choice) as everyone else, there is no such universal truth. And no development process I've encountered so far was that "industrialized" - if it were, I'd not call it software engineering but software assembly - and it probably should be automated by then.
Now, on the other hand. If you want to code, at some point you need to edit the code in some way. So if you make the measure broad enough and count any editor in that could be used and pick the number low enough, then you can determine a minimal number like 10% a week that securely covers all successful coders (that are paid to develop software rather than do some other tasks). At that point it obviously gets quite meaningless - i.e. someone who slacks off so much they would be detected by that measure, should in any functioning company be detected much earlier by other means (e.g. by not having anything meaningful to say in a daily standup meeting for days).
Now there is a gray area in-between where you can use such a metric as an indicator, with other metrics to see whether someone needs support. But that is another ball park entirely of aiming for a perfect usage percentage. And again, there would be other metrics that cover the same cases without giving employees the feeling to be monitored and not trusted.
Therefore, your real question should not be "is there such a number?". Your real question should be "How do I get management to back the fuck off trying to manage me like a line worker that only works when being strictly monitored?" *
Or more nicely, how to get management to see that this measure is not helping anyone, but destroying self-determined work and thus personal work investment along with any good will and trust.
* Note that these are two separated parts: 1) being treated as a line worker 2) that is lazy when not monitored → i.e. I'm not saying every line worker needs monitoring either.