Shouldn't it be "had he looked."? Also the second rendition makes doesn't include what the rest of the joggers are doing, yet the first one does. Not sure if intentional. At first I gasped at your practice, because I never do that, but I see the point now. Mastery of language.
> Also the second rendition makes doesn't include what the rest of the joggers are doing ... Something is amiss here.
Karma/backlash for my rude post. I will leave it unedited, but s/makes// in case it is not clear.
In C, you can wrap the 'commented' code with #if 0 ... #endif
I would do a bit more by #if !defined(this_works_but_it_suck_memory_too_hard) .... #else .... #endif That should give me a clue why I "disabled" it when I come back to it 5 minutes later.
I usually just do this with a comment behind the #if false. Yes, nobody is probably ever going to define that particular identifier, but comments are also less restrictive (you can write normal text).
When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…
My approach is similar to this, except for whole functions/classes I tend to just create a new one with a version number. e.g. DataContext => DataContext2. When I'm satisfied that DataContext2 does everything that DataContext does, I delete old one and rename DataContext2 => DataContext. The risk here, is that sometimes it's not possible to migrate everything to the new version and you end up with multiple old versio…
I do the same, but the opposite way, hehe - I rename e.g. "DataContext" to "DataContextOLD1", then I write the new "DataContext" (from scratch or by copying the original one and then modifying it), this way I'm sure that all calls to DataContext always use the new version.
This feature is absolutely outstanding, I use it all the time. Unfortunately they buried it in the "File" menu recently. It was so much easier to reach when it was unter "Version Control".
You can assign a custom shortcut to it via Settings > Keymap and then the action "Main Menu > File > Local History". I myself have assigned the shortcut control+shift+=
Thanks, did that. I decided on Alt+Z, because Ctrl+Z is Undo, so I though this makes sense.
My favorite IntelliJ feature is that it tracks the full history of the files in your project, losslessly and independently from your VCS. You can just go and pull source from Local history, from 5 minutes or 5 days ago (I'm not sure how far back it goes, I've never needed more than a week). Not something I use often but as a last ditch effort to find code that I've spent hours or days on and subsequently lost to a gi…
When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…
When editing lab notebooks, it's customary to finely cross a line through data or notes you wish to discount without affecting their legibility. It's also expected that any edits or annotations be circled, dated, and initialed.
The point is that data is never destroyed, and this is one of the many causes for the unflagging preference for tangible records over ELNs.
My favorite IntelliJ feature is that it tracks the full history of the files in your project, losslessly and independently from your VCS. You can just go and pull source from Local history, from 5 minutes or 5 days ago (I'm not sure how far back it goes, I've never needed more than a week). Not something I use often but as a last ditch effort to find code that I've spent hours or days on and subsequently lost to a gi…
Personally I just use git for that. Even if I'm not 100% happy with some solution, I put it into a commit and then do subsequent improvements, or just remove it again entirely.
But then you end up having to clean up your git history before committing to the shared branches, with squashes and rebases, which is annoying.
I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.
As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.
I like to put a space following the // if it's written text comments, but no space if it is commented-out code.
I think the space looks nicer for text comments, but when I select a block of code and hit Ctrl+/ to comment it out, my IDE does not add a space. So it works out very conveniently for me.
Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory." Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming…
Development often times entails a lot of trial and error, and there is nothing wrong with that. If you have fast iteration cycles, you can fail many times before you settle on an optimal solution.
That usually depends if you are writing something from scratch, or wrestling with other peoples libraries.
When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…
I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.