In some cases (see discussion here for instance) moving code to always blocks is detrimental to readability, as the semantics get split and spread in different places.
A straightforward possibility would be to allow inline always blocks. In that case all always blocks would be concatenated together, into one global always_before and one always_after block.
Upsides:
we improve readability and maintainability (by avoiding missing side effects of the always blocks defined outside)
Potential downsides:
different always blocks may interact in ways that will not be obvious at first sight (e.g. assigning to same variables)
inline always blocks may be confusing?
Syntax highlighting can likely help with identifying the blocks clearly. The linter could warn on non-conditional conflicting assignments?
In some cases (see discussion here for instance) moving code to always blocks is detrimental to readability, as the semantics get split and spread in different places.
A straightforward possibility would be to allow inline always blocks. In that case all always blocks would be concatenated together, into one global
always_beforeand onealways_afterblock.Upsides:
Potential downsides:
Syntax highlighting can likely help with identifying the blocks clearly. The linter could warn on non-conditional conflicting assignments?