|
APL is the language for you!
|
|
|
|
|
A bit verbose that one. I'll stick with Brainfuck[^] 
Mircea
|
|
|
|
|
I once wrote a program with a variable
int hell_freezes_over = 0;
The loop control was
do
...
until hell_freezes_over
The languange didn't support infinite loops.
|
|
|
|
|
I did something similar, but my symbol was WW3.
A friend of mine pointed out that I was a romantic dreamer: I had defined WW3 as a false constant 
|
|
|
|
|
And what is wrong with the idiom:
for (;;)
{
}
Which has no spurious conditions?
Inquiring minds wish to know!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
trønderen wrote: According to him, there is one, single way of coding an infinite loop, that is immediately recognized by every programmer in the world, and that is 'while (1)'
(Changed the 0 to 1 per your earlier replies)
Lint may disagree with his assertion that while(1) {} is the only and preferred way to write a loop - I have had it prefer the for(;;) construct and both are versions that are easily recognised.
I wouldn't personally be a fan of "#define ever ;;" as it "feels" fragile both in requiring the definition be included consistently and the risk someone may one day want to name a variable or function as that. Would be something for an interesting private discussion rather than "show and tell" at a scrum meeting, however!
|
|
|
|
|
trønderen wrote: his construction made my coworker so upset that he not only changed it where he had discovered it; he searched through the entire code base of the company for other uses, and found a good handful; I had been programming with 'for (ever)
Myself I take the view that I am working in and for a business. So I write code with the view that someone in the future will need to read my code, understand it, and modify it to meet the needs which I cannot possibly predict when I write the code. So I try to make the code as easy to understand as possible.
So it is not what I want but rather how to best produce something that is more useable for the future.
|
|
|
|
|
You speak of of your conclusion as if it was universal. Maybe your workplace culture leads to poor code reviews. That does not mean that code reviews cannot be done in a productive way. Cheerz.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
well.. lucky you. the larger the team the higher the chance to have that coworker (those coworkers?) who wants to micromanage reviews
|
|
|
|
|
Very true. Perhaps even more true for large companies. Also true: there are many more reasons to avoid large companies, if you value your sanity.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I review books. From Manning. I never had to ask them to change code. Ever.
If you want to make a proposition for change, you ask yourself what it is worth. Does your idea add value?
If not, then SHUT THE F*** UP.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
In one place, we wrote pseudo-code before coding. We reviewed the pseudo code. That's it. (i.e. the programmer / analyst gets it).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Years ago, I had the same.
A colleague wrote an export routine to export a number of tables to an XML file.
The tables where already loaded in memory.
He came up with an over the top export routine of about 20.000 lines of code.
He had been working on it for 3 weeks.
I had to do the code review.
I looked at it and rejected ALL of it. (And I wasn't revengeful)
I told him we could do it with ONE little statement. (ds.GetXml() - where ds is the already loaded DataSet)
He never spoke to me again until I left the company. 
|
|
|
|
|
You feel this way partly because a lot of people do code review wrong.
Y'all need to check out Dr Michaela Greiler:
1. Follow https://twitter.com/mgreiler if you use the bird site
2. Read her code review checklist
3. Perhaps book a code review workshop if your team is really getting bumpy around code review time (I haven't worked through any of her workshops, but have a lot of faith they will be good based on her newsletter)
Where I work, code review is an integral part of the dev cycle. No code gets back into the main line without review. When I joined the place I work at now, code review was new to me. Often it felt like brutal, unnecessary nitpicking. What's changed since then is two-fold:
1. all of us are striving to be better reviewers, because (a) that's good for the product, (b) that's good for the reviewee (fostering good relationships and the ability to learn), (c) that's good for the reviewer (not wasting time on pointless bull💩)
2. I think we've all learned to detach the self from the code. You are, in the words of Tyler Durdin, not your fscking car keys. You are not your fscking code. You are fallable, like everyone else, and can, when open to it, learn, both to be a better coder, and to be humble, which makes you a better person.
Just because your code has an issue, it doesn't make you less of a person, or even less of a coder. It just grants you an opportunity to learn, when someone helps you discover that issue. Of course, that "someone" has to learn how to review without personal attack - see recommendations above.
------------------------------------------------
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing
Which is stupid.
|
|
|
|
|
Too many people treat code reviews as a way to pick apart someone's efforts. Personally I look at them as a way to ask questions, offer suggestions and even as a learning opportunity for myself and the rest of the team. If someone has found a better way of performing a task, it gives us all a chance to absorb that lesson and use for ourselves.
It should be a two-way street, with the reviewers having that opportunity to see and understand the nature of the new/added code.
Egos need to be left at the door when doing these reviews, and the participants need to keep an open mind...
|
|
|
|
|
Occasionally, a review of proposed algorithms for solutions (not VS solutions) would have pseudo code presented to the group. It helped establish the flow chart of logic to the solution. No review of code was required. As professionals it was assumed we knew what we were doing. There were exceptions such as debugging problems, etc. but rare as a group. Our shop was not that large so meetings were more often 1 on 1. Picking apart code was something done by our professors in school, or by a selected colleague. You were responsible for picking apart your own code. If your code had to be plugged into a system, then a dummy system was used to test it. Here a group meeting might be called to review that test, before going live. It has been awhile and things have changed including coding. Richard Hamming, American Mathematician (Hamming code fame)
"Mathematicians stand on on each other's shoulders and computer scientists stand on each other's toes."
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Super Lloyd wrote: I often feel like code review are mostly filled with unneeded comment for the sake of commenting or to take some sort of "ownership" that doesn't do anything special beside burdening the reviewee with a special cosmetic change udpate.
All I can say in my experience of many years is that reviewers often do nothing but rubberstamp the review process.
So if you are seeing this from many people I would be curious exactly what they are commenting on so frequently in your code.
Super Lloyd wrote: was doing unnecessary work in Dispose() because "that's what is done everywhere", even though it's not needed and closing documents take godamn too long (due to all those unnecessary piece of code running in all those Dispose()
If you have a "document" which is taking too long to close and you have actually profiled the problem to be a problem with Dispose method then I would question your architecture and design. Or perhaps the definition of "document".
|
|
|
|
|
Wordle 591 3/6
🟨⬛⬛⬛⬛
🟩🟩⬛🟩⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 591 6/6
⬜⬜⬜⬜⬜
⬜🟨🟨⬜⬜
🟨⬜🟩🟨⬜
🟨⬜🟩🟩⬜
⬜🟩🟩🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 591 4/6
🟩🟩⬛⬛⬛
🟩🟩⬛🟩⬛
🟩🟩⬛🟩⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 591 2/6*
⬜🟩🟩🟩⬜
🟩🟩🟩🟩🟩
I was lucky with the first one.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 591 5/6*
⬜⬜⬜🟨🟩
⬜🟨🟨⬜🟩
⬜🟩🟩⬜🟩
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
|
Wordle 591 4/6
⬛⬛🟨⬛⬛
⬛⬛🟨⬛🟩
⬛🟨⬛⬛⬛
🟩🟩🟩🟩🟩
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
🟩🟩⬜⬜⬜
🟩🟩⬜⬜⬜
🟩🟩🟩⬜⬜
🟩🟩🟩🟩🟩
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 591 4/6
🟨⬜⬜⬜🟩
⬜🟩🟩🟩🟩
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
Gah! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
