Don’t do this. Like @jimtng mentions, there’s a “Member of GroupItem” set of triggers that will trigger the rule when any member of the Group emits the indicated event. You can find out the name of the Item that triggered the rule through the implicit variables (assuming Rules DSL) or the event Object for the other rules languages.
In addition, sending a command to a Group Item forwards that command to all the members of that Group. So if you have three Switch Items that control all should be controlled together, you can make them all a member of the same Group and send ON/OFF commands to the Group to control the lot of them all at once.
Beyond that, if you are using files for rules organize them as makes the most sense to you. I recommend a functional organization where rules that do similar functions (e.g. lighting) are all in the same file. These rules are more likely to have common code and common needs so putting them together makes it easier to reuse code and whatnot.
Be sure to review the Design Pattern posts for some ways to solve common problems in OH rules. I’ve recentlty updated most of them so there are at least Rules DSL, Blockly, and JS Scripting examples in most of them. Design Pattern: Associated Items - #26 by requireiot and Design Pattern: Working with Groups in Rules - #183 by rlkoshak are particularly useful to make a single rule generic so it can handle lots of Items.
Don’t miss out on profiles too. Some of this might be able to be done from the follow profile or a script profile instead of a rule.
In the UI, definitely use tags and the developer sidebar (alt-shift-d) to find and pin all the stuff you are working on at any given moment. What I like about the developer sidebar is you essentially get to set up an adhoc organization for exaclty what you are working on at any give time. And this includes Items, Things, Pages, etc, not just rules.
For example, if I wanted to work on my time based rules I just search for “time” and pin the stuff I need.
Clicking the pencil icon navigates striaght to the entity. Once pinned, Items can be controlled, rules run, enabled, disabled, etc all from the sidebar.
So far I find that if you use maningful names, fill out the descriptions, and add comments to the code and that’s enough. I actually rarely use tags for rules any more (though it makes me happy rules instantiated from a template are automatiaclly tagged with the template ID). They aren’t always needed.
Also note that the search function also searches inside the rules/items/things configs so it can also be used, for example, to find all of your JS Scripting rules that are using the old .history instead of the new .persistence.
If you have managed confilgs, it’s worth the effort to learn the developer sidebar. It is where your organization is going to happen.