Code a little difficult to read. about invoke-build

[nightroman]

Is this a question or a suggestion?

If this is a question. This is because it is easier for me to have a lot of code on my screen for analysis and thinking of it at once, without scrolling or changing pages.

If this is a suggestion. What is it exactly?

P.S. Wow, the first issue! And it is "The complexity per line is very high" :)

[carwyn]

I was wondering if there was a functional reason for the code density. Hence a question.

In terms of a suggestion I suggest it would be easier to reason about the code if it was less dense and where there is complexity break it down into functions that fit on a screen rather than pack it all in to one. It would certainly be easier for contributors or users trying to understand the code.

Debug tools tend to be line based, with this amount of cyclomatic complexity per line it's almost impossible to step though.

We were looking to use Invoke-Build for our internal builds and deployment. But our developers had concerns about the readability.

We like what it does, but this was an issue for us. We thought we'd feed it back as we'd be using it if it wasn't for this.

[nightroman]

The tool is, in my opinion:

• somewhat feature complete (so I do not expect much contributions)
• well documented (help and wiki) (so I do not see much reasons to read the code)
• somewhat bugs free (so I do not expect much debugging), if it is not, submit a bug

Nevertheless, what a user wants is very important. I'll reduce density of the code in the version next. As an example, is Build.ps1 (yet another script from the package) code density good enough?

[carwyn]

Build.ps1 - Yes much better in terms of readability (maybe a tiny bit too far in the other direction?). I can see your point in terms of fitting on a screen although surely breaking up the code further into functions would help with this?

We have to think about long term maintainability even in the cases where the original author may have moved on. Hence we have to accept that we would in those cases be maintainers on code for projects that has 5-10 year life spans. This is why we care about this. It's come down to Invoke-Build vs other tools. We have to think about what we'd have to do if the maintainer had moved on and the code broke with PowerShell 5 for example.

[nightroman]

Good points. I did not think of this at such an angle. I am going to use and support this tool for long time (and I use it a lot) but yes, who knows... All right then, wait for the next version.

[nightroman]

It's done in v2.4.7. This is my "normal" script style, i.e. "not condensed". I would not like to change it, now it's a matter of personal preferences, not readability or easier debugging (I agree that "normal" style is better for this).

[carwyn]

That's much easier for my poor little head to understand :)

Would I be correct in thinking you are using * prefixes for function names to mean internal private functions?

"-" prefixes for function local private variables?

Thank you very much for doing this!

[nightroman]

Yes, * is for (pseudo) internal functions, - is for (pseudo) internal variables. Making variables just private is not always enough, user code is invoked sometimes dot-sourced, so that private variables are in the same scope and still may conflict with user's. Use of weird names reduces chances of conflicts. Also, there is one public internal variable ${*}, it is public for internal needs, sort of $this for the build engine "methods". Most of these details are mentioned by wiki.

I am closing the issue. Thank you for using Invoke-Build and for the report.

[nightroman]

A little bit late perhaps. Anyway, as far as you evaluated several tools, you may see better than I how Invoke-Build may be improved. Please, do not hesitate to share your thoughts.