[deleted]
Every line of code is always documented
11–20 of 104 posts
Re: Every line of code is always documented
#12"is it safe to change or remove that call in the future?"
If you remove the line you should end up with a failing test.
Re: Every line of code is always documented
#13You really shouldn't have to be relying on history for all of that context. It should definitely have been a function simply called 'triggerLayout()'. Then the exact and best method for triggering layout could be put in that function and used throughout the project where necessary, and easily updated if a better method of triggering layout comes along. Code like this is extremely brittle with or without that git hist…
"Code happens". In reality, there's code that should have been commented all the time and even in the best codebases. I don't think there's a coder in the world who hasn't had a time when he's looked back on a piece of code and just thought "what?". If you get in the habit of keeping a well documented git history, it's an invaluable resource. I find on top of these benefits, having to explain what changes I made also helps me make smaller and easier to understand commits, which also helps with summarizing releases, finding commits where bugs were fixed or introduced, and so much more. A well documented git history is the closest thing to a time machine you can get.
Should these things happen? No. Do they happen? All the freaking time.
Re: Every line of code is always documented
#14"is it safe to change or remove that call in the future?" If you remove the line you should end up with a failing test.
Good luck writing a test that makes sure that the CSS animations get properly triggered on select browsers.
Re: Every line of code is always documented
#15You really shouldn't have to be relying on history for all of that context. It should definitely have been a function simply called 'triggerLayout()'. Then the exact and best method for triggering layout could be put in that function and used throughout the project where necessary, and easily updated if a better method of triggering layout comes along. Code like this is extremely brittle with or without that git hist…
"Code happens". In reality, there's code that should have been commented all the time and even in the best codebases. I don't think there's a coder in the world who hasn't had a time when he's looked back on a piece of code and just thought "what?". If you get in the habit of keeping a well documented git history, it's an invaluable resource. I find on top of these benefits, having to explain what changes I made also…
What? No, it's got nothing to do with commenting. It's to do with basic code design: put your stuff in functions. A line like that should have been in a function to start with, and it should have been caught during a code review or as common sense by the committer before he even committed.
Re: Every line of code is always documented
#16> var one = "foo" , two = "bar" , three = "baz" Agree with the author that this is easier to change, and in JS it will keep you from accidentally leaving a trailing comma. That being said, I find it to be very unreadable(which is where most your time will be spent) and most text editors/IDE's make it a burden to work with.
While I agree with making code editable in single lines as much as possible, I think this is a particularly bad example. I do prefer the comma first style for arrays and objects, but not for variable declarations. I used to use this exact style a couple years ago, but now I prefer to explicitly declare every variable with `var` to prevent any possible, syntactically correct, error that would result in a global variable.
Re: Every line of code is always documented
#17Every line of code is always documented (if it's in a VCS and the commit message is good)
Re: Every line of code is always documented
#18Interesting concept.
Coincidentally, I wrote a gem recently that serves the same function as the git-overwritten script at the end:
https://github.com/ilyakava/stefon
gem install stefon
Re: Every line of code is always documented
#19You really shouldn't have to be relying on history for all of that context. It should definitely have been a function simply called 'triggerLayout()'. Then the exact and best method for triggering layout could be put in that function and used throughout the project where necessary, and easily updated if a better method of triggering layout comes along. Code like this is extremely brittle with or without that git hist…
Way to miss the point completely.
Re: Every line of code is always documented
#20It sounds like "this.get(0).clientLeft" should have been a single-line function named something like triggerLayoutInMozillaAndFirefoxToFixAnimateForNewDomElement, or if you don't like massive function names, a comment that says that. Spelunking through commit history shouldn't be necessary learn the intentions behind those kinds of actions.
It doesn't matter if it should have been commented or not. The reality is it wasn't. If you get in the habit of explaining your changes in git messages, every line change will have documentation, or at least an owner so you can ask them about it. If you do need to go git spelunking to figure out what's going on, you'd have to be insane to not add a comment afterwards. Either way, "shoulda coulda woulda". If the code…
According to your logic, the author of this code should write a detailed explanation in the commit message, except he probably won't. Shame isn't it?