You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 onealways_after
block.Upsides:
Potential downsides:
Syntax highlighting can likely help with identifying the blocks clearly. The linter could warn on non-conditional conflicting assignments?
The text was updated successfully, but these errors were encountered: