Hi everyone.
I need to find all unused elements in my project (such as global constants, types, variables and subroutines) and remove them from the source code. I am talking about elements that are declared in the units of the current (opened) project.
How can I do that? I don't see any option in the environment.
There are hundreds of constants in the project (not to mention the rest elements), so manual checking (eg using the "Find or Rename Identifier" or "Find in Files" tools) would take a very long time and it would drive me crazy.
Is there a way to automate this task?
Obviously, if "elements" are global, i.e. located in such scope, where it could be accessed by anyone (units not listed in project, units in other projects), the term "unused" is not applicable.Yes, but I think it would be good to have a tool to show you unused element in the interface if you want to know them.
Normally, one should have a reason for identifier to be in global public scope. And if you have a lot of identifiers that became "unused", you should reconsider your code structure. Not just "clean unused".
Normally, one should have a reason for identifier to be in global public scope. And if you have a lot of identifiers that became "unused", you should reconsider your code structure. Not just "clean unused".
But with the things we have now, the only workaround I can think of is to move all constants, types and vars to the implementation section.
Well, I said there should be a reason, and perhaps you have one, but I could hardly imagine 300 const identifiers in platformer game :).
The only kind of automation I'm thinking about is to use CodeTools' parser and write your own cleanup procedure (not easy).
It is in certain way.Normally, one should have a reason for identifier to be in global public scope. And if you have a lot of identifiers that became "unused", you should reconsider your code structure. Not just "clean unused".
I do not understand why the need to find unused "identifiers" is considered by you as a sign of poor code quality.
But with the things we have now, the only workaround I can think of is to move all constants, types and vars to the implementation section.
Yes, but it is a different way of manual search.
It is faster to check the identifiers with the Find in Files tool, which can be easily operated from the keyboard. If the list in the Search Results window contains only one item (declaration line), it means that the constant is not used anywhere else.
Yes, but I think it would be good to have a tool to show you unused element in the interface if you want to know them.A tool or the compiler
It's very common in projects born as a proof of concept or experiments which suddenly become serious without: stopping to look what was done and how could be improved.
Then outline a basic diagram (anyone you think could help you), how you will allocate your resources and constants.
Question any global variable, constant, resource, and type: When are needed?
Which class or process needs it?
Is it OK that could bee seen or used in places where is not needed? etc.
Believe me. Probably the project needs it. You will be surprised of what you'll find: methods, functions and procedures which are not used which in turn use constants or types not used in other places, things that should be in other unit, etc.
A tool or the compiler
[…]
You should open a Ticket in the bug tracker as requirement for the compiler....
some special option for the compiler (turned off by default) would be a better solution.That will be the ideal. Though I don't know if it easy to implement or not. FPC core developers should know. With a ticket at least one of them will take it if it's possible or a no go.
The only reason why there is no such for global identifiers is because it's not needed for each or most projects.
If you are interested I can add the inspection (disabled by default) for global identifiers to I-Pascal.
I agree with this statement only if the majority of created projects are libraries, packages and everything else that is non-executable.I don't think that's the logic behind the "No interface's element will be reported as not used" thing...
I don't think that's the logic behind the "No interface's element will be reported as not used" thing...
[…]
I think the logic is "what you put in the interface is something you want to share that element with other units so can be used at will" sort of thing.