Hi @camarosan,
Sorry this reply is 2 weeks after you asked the original question, but Iâve noticed that you didnât get a reply and your questions are interesting ones⌠so⌠hopefully, better late than never⌠
In Solidity (unlike JavaScript) we define the data type when declaring a variable. This means that if we want to initialise a variable with its data typeâs zero-equivalent value, then we can leave it unassigned, and Solidity will assign the zero-equivalent value to it by default:
uint private variable; // variable = 0
int private variable; // variable = 0
bool private variable; // variable = false
string private variable; // variable = ""
Here is a link to a useful discussion about this:
https://ethereum.stackexchange.com/questions/84270/why-solidity-doesnt-use-null-and-undefined
Yes, it will consume a small amount of additional gas because of this.
Yes, you can add more code and more operations to a modifier in addition to a require statement, but I would say that there is a reason why you shouldnât do that in this particular case:
It is better practice, and almost certainly safer from a risk management perspective, to perform all of the require checks before making changes to a contractâs state (here, increasing the balance). Even though your modifier increases the balance by msg.value before checking that age < 150, it is true that if the age check then fails, all of the operations performed previously in the function call (including the balance increase) will still be reverted. However, the more operations (and especially changes to state) that we allow to be performed before a potential revert can be triggered, the more we are increasing the risk of introducing vulnerabilites into our code. In addition, even though all operations would be reverted, the gas already consumed by each operation isnât refunded.
You should also bear in mind that the whole point of using a modifier is to avoid code duplication across multiple functions. The more functionality you add to a modifier, the less reusable it becomes. In this particular case, I think it is clear that whenever calling a function requires a payment, then this amount would also need to be added to the overall contract balance, but, generally speaking, you should certainly think carefully about whether you are restricting your modifierâs usability by adding additional code to it. We should also remember that our code is generally clearer and more secure, the more modular it is, and so itâs good practice to try to allocate code for different tasks to separate functions and modifiers. However, again, there is certainly a case to be made here that increasing the balance by the payment amount is part of the same task as checking that the amount is sufficient.
I hope this goes some way towards answering your questions. Do let us know, though, if you are still unsure about anything. Keep up the great work! 