src/Config-Network.ps1 splits adapter selection across three functions. Two of
them have one caller each:
| Function |
Lines |
Real logic |
Callers |
Test-WcdNetworkAdapterActive |
22 |
one regex, ^(Up|Connected)$ |
1 |
Get-WcdActiveNetworkAdapters |
26 |
one Where-Object |
1 |
Test-WcdRelevantNetworkAdapter |
35 |
the virtual-adapter exclusion list |
1 |
Apply the deletion test to the first two: inline them and complexity moves, it
does not concentrate. One caller each. They were extracted to be testable, not
because anything else needed them.
The third is different. That exclusion pattern — bluetooth|loopback|isatap| teredo|vmware|hyper-v|vEthernet|virtual|vpn|wan miniport|miniport|pangp| anyconnect|juniper|tap — is the real domain knowledge in this file, and it is
the thing that will actually be edited when a site's VPN client shows up in the
summary and shouldn't. Right now it is buried between two functions that do
nothing.
Note the tax
Every named function here costs ~20 lines of comment-based help, because
tests/Help.Tests.ps1 requires a synopsis, an example and a documented
parameter on all of them. That is the right rule for a Module's entry point and
an expensive one for a one-line predicate. Worth knowing when deciding whether
the next helper deserves a name.
What changes
- Fold
Test-WcdNetworkAdapterActive into Get-WcdActiveNetworkAdapters
- Promote the exclusion pattern to a named script-scope variable at the top of
the file, where someone looking for it will find it
- Keep
Test-WcdRelevantNetworkAdapter as the function the test targets
Honestly: low priority
Small win, real churn, and the current shape is not hurting anyone. Filed
because it is the clearest example of the pattern in the repo. Take it if you
are already working in Config-Network.ps1; do not make a trip for it.
Done when
src/Config-Network.ps1splits adapter selection across three functions. Two ofthem have one caller each:
Test-WcdNetworkAdapterActive^(Up|Connected)$Get-WcdActiveNetworkAdaptersWhere-ObjectTest-WcdRelevantNetworkAdapterApply the deletion test to the first two: inline them and complexity moves, it
does not concentrate. One caller each. They were extracted to be testable, not
because anything else needed them.
The third is different. That exclusion pattern —
bluetooth|loopback|isatap| teredo|vmware|hyper-v|vEthernet|virtual|vpn|wan miniport|miniport|pangp| anyconnect|juniper|tap— is the real domain knowledge in this file, and it isthe thing that will actually be edited when a site's VPN client shows up in the
summary and shouldn't. Right now it is buried between two functions that do
nothing.
Note the tax
Every named function here costs ~20 lines of comment-based help, because
tests/Help.Tests.ps1requires a synopsis, an example and a documentedparameter on all of them. That is the right rule for a Module's entry point and
an expensive one for a one-line predicate. Worth knowing when deciding whether
the next helper deserves a name.
What changes
Test-WcdNetworkAdapterActiveintoGet-WcdActiveNetworkAdaptersthe file, where someone looking for it will find it
Test-WcdRelevantNetworkAdapteras the function the test targetsHonestly: low priority
Small win, real churn, and the current shape is not hurting anyone. Filed
because it is the clearest example of the pattern in the repo. Take it if you
are already working in
Config-Network.ps1; do not make a trip for it.Done when
Test-WcdNetworkAdapterActivefolded into its callertests/Config-Network.Tests.ps1still covers the exclusion behaviour directly