Adding comments in code vs writing self-explanatory functions, variables, etc. #1230
-
Now that I'm learning about TCA and using many of Brandon and Stephen's open source examples as guides for developing my own app, I noticed that there really isn't any documentation anywhere in the code outside of the Composable Architecture framework and I was wondering whether this is intentional (e.g. isowords' AppView.swift). This question isn't coming from a place of criticism at all, and it wouldn't surprise me if one of the benefits of TCA is not needing to add a comment to every variable or function in a struct. The architecture makes it very easy for any developer to just understand what is happening, what actions trigger events, etc. (assuming the programmer is able to come up with somewhat decent enum/struct names ;) ). I just want to develop good programming habits and not have to spend more time than needed writing potentially bloated code :) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
A few days into hypermodularizing my own app, I can 1000% see why Brandon and Stephen don't add comments, header comments, function comments, etc. in their example code. Having to create many files, objects, etc. it feels absolutely boilerplate-y! For instance, I have to update the header comment to reflect the correct filename, correct module (SPM isn't friendly with macros, which would make autogenerating headers possible), and the filename could certainly change considerably when developing. Lots of their code also takes advantage of synthesized initializers (which is visually great and clean), and it would bloat the code quite a bit having to explicitly call the initializer just to add comments on what is probably quite self-evident. I think I'm going to go about adding comments only when there's something that isn't obvious in my code :) |
Beta Was this translation helpful? Give feedback.
A few days into hypermodularizing my own app, I can 1000% see why Brandon and Stephen don't add comments, header comments, function comments, etc. in their example code. Having to create many files, objects, etc. it feels absolutely boilerplate-y! For instance, I have to update the header comment to reflect the correct filename, correct module (SPM isn't friendly with macros, which would make autogenerating headers possible), and the filename could certainly change considerably when developing.
Lots of their code also takes advantage of synthesized initializers (which is visually great and clean), and it would bloat the code quite a bit having to explicitly call the initializer just to ad…