|
Do children who don't learn to tie their shoes end up on Santa's knotty list?
"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!
|
|
|
|
|
And where do those hang (around) who can't tie their ties 
modified 20-Dec-21 11:18am.
|
|
|
|
|
Yup, and those children who don't wipe their noses end up on his snotty list.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
I don't recall hearing about a snotty list, but I've heard of a shite list, which still works.
|
|
|
|
|
Greg Utas wrote: shite list
My mom claims I was on it more often than not. 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
I bet you have been hitching to tell that one!
Take a bow, line up the rest of the weeks TOTD, kiss your Granny, and have a merry Christmas!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
One, two, Velcro my shoe.
>64
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Hi, Everyone!
The Old Year 2021 slowly comes to an end.
My warmest greeting on a very Merry Christmas and upcoming Happy New Year of 2022!!!
As one of the old CodeProject's community members,
I would like to wish all of You a peaceful, joyful, and of course, very Merry Christmas holiday,
and Happy New Year of 2022, full of creative inspiration, joy, prosperity, and luckiness of everything in the upcoming year!!!
Thank You very much, all!!! 
And, here's my greetings card, in the link below:
Christmas Songs 2022 New 🔔 Music Club Christmas Songs 🎅🏼 Merry Christmas 2022 🎄 - YouTube[^]
|
|
|
|
|
Arthur V. Ratz wrote: and Happy New Year of 2022
Still feels like an unrealistic number.
Merry Christmas and a joyful new year
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.
|
|
|
|
|
But It's upcoming very very close 
|
|
|
|
|
Yeah. I will party like it is nineteen nigthy nine. You welcome, but need sign a waiver.
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.
|
|
|
|
|
Merry Christmas, all the best for the New Year 
|
|
|
|
|
very Merry Christmas, and You too.
|
|
|
|
|
Right back at you! 
Moist Von Lipwig
|
|
|
|
|
For the Three Wise Men: "Oh Camel Ye Faithful"
"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!
|
|
|
|
|
Tom Lehrer suggested:
Given that the true spirit of modern Christmas is the commercial spirit, perhaps Christmas carols should be updated as follows:
- God rest ye merry merchants, may ye make the yuletide pay
- Angels we have heard on high, tell us to go out and buy
- Hark, The Herald Tribune sings, advertising wondrous things
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I'm browsing through the labyrinth of MSDN and I am seeing more and more use of expression bodies.
eg
public MyObject(string name, string data) =>
(_name, _data) = (name, data);
as opposed to
public MyObject(string name, string data)
{
_name = name;
_data= data;
}
This makes me feel old because it reminds me of when we used to cram our code into as small a space as possible to handle 25 line screens.
Maybe this is like skinny jeans: in a year's time it'll all be over.
cheers
Chris Maunder
|
|
|
|
|
And 80 (or possibly 132) columns. I still use vi & emacs for programming, but always use 132 column mode. I still run into line-wrap on a regular basis. My colleague still prefers 80 column mode - we are dinosaurs, after all - and I have to confess I have no idea how he puts up with it.
Keep Calm and Carry On
|
|
|
|
|
k5054 wrote: And 80 (or possibly 132) columns.
At work, we were developing a new company C coding standard. One of the proposals was to limit source code lines to 80 cols. Our project manager immediately declared that he would grant an unconditional exemption to that rule: We had rules for how to name #define constants that lead to identifiers exceeding 80 chars. So the 'max 80 col lines' did not make it into the standard.
We retained the rules for how to name #define constants. Many times later, I have questioned whether we retained the right rules. Maybe we should have accepted 'max 80 col' and rather revised the naming rules.
|
|
|
|
|
You got some kind of issue with integerToCountFromOneToOneHundredInForLoopInIfMyValueIsTrueBranckOfMethodFooOfObjectBarInClassBas? I suppose you think it should have been called i or something, you Philistine!
|
|
|
|
|
Change for just "Change's sake is never a good thing.
If there is a legitimate reason, then OK.
Old guys don't die, they just fade away...
|
|
|
|
|
I do not know C# and never tried to use it but, if they were going to change their parser to accommodate a new syntax, they could have gone the extra mile and do something inline like
public MyObject(string name=>_name, string data=>_data){}
I have been secretly wishing for something similar for constructors in C++. Example
MyObject(std::string name=defaultName:_name, std::string data=defaultData:_data){}
instead of what we have now
MyObject(std::string name=defaultName, std::string data=defaultData):_name(name),_data(data){}
There would be less typing.
Or go a little further and allow for static functions to be called to evaluate values. Example
MyObject(std::string name=evalName():_name, std::string data=evalData():_data){}where "evalName()" and "evalData()" would be automatically passed the given parameter value. The signature would be
std::string evalName(std::string name)
|
|
|
|
|
Chris Maunder wrote: This makes me feel old because it reminds me of when we used to cram our code into as small a space as possible to handle 25 line screens.
I do appreciate fitting an entire function/method on the screen, especially when I didn't write the code myself (or I wrote it so long ago that I no longer remember my line of thought), and need to read the code forwards and backwards and from both sides to understand the logic.
With the 60+ line editor windows of today, you'd think that was a modes request. But with the modern style of always putting braces on separate lines, always put braces around even a simple assignment if it is e.g. an if clause (so the minimum number of lines for an if statement is 4). Some people even insist on always putting blank lines before and after any 'structured' statement (such as if/else, loops etc.), making 5 (or even 6, depending on context) the minimum line count for a simple 'if' ... Then you certainly won't be able to fit any large fraction of real-life methods in a 60 line editor window, or the hardcopy equivalent: One printed page. If you also forbid end-of-line comments, requiring comment to have their own lines (this has been the case in the majority of projects I have worked on, you frequently see 60 line windows "crammed with code" (according to the coding standard, but really containing no more than 5-8 statements.
When I write code independent of such spacing requirements, I succeed in fitting maybe half of the function bodies below 60 lines. Then I e.g. put the opening brace at the end of the first line, and I accept un-braced single assignments as if/else clauses, following the condition or the 'else' keyword on the same line. A short (typical: half line) comment is written from col 70 of the line to which it applies, or col 90 if many source lines are long - I want the option to 'semi-ignore' the comments; when I know the code, comments should be there, but no clutter up the actual code statements.
If I want people to review code written this style, I may print it double spaced (today, when most code reviews are made on-screen, I can just replace every newline with two newlines), to give other developers something in that 'airy' style that they want. No one ever remarks anything about blank lines around all statements, not just structured ones. That makes every statement clearly defined. It is considered making the code 'easier to read' (just like children's books usually has significantly larger line spacing than books for adults).
I knew one guy who was almost totally blind, yet an eager program developer. He read (and edited) the source code on a braille line: With his fingertips, he could read one line at a time, scrolling up and down a line at a time. He sort of kept the entire source code inside his head, using the braille line primarily as a tool for finding the right spot for his corrections or amendments.
When I read that airy kind of code, newlines as frequent as spaces, where I have to page down, and down, and more down, ... and then return to maybe six pages higher up, I feel a close relationship with my almost-blind friend: I must keep structure of the code in my head. I won't have the option to see it on the screen. Not unless I get myself a minimum of three huge, high resolution screens, stacked one above the other, in portrait orientation. And a ladder to climb up and down the code strand.
A common APL joke is that every APL programmer's dream is to write the entire problem solution in a single line. It looks as if a fair share of C programmers' ultimate dream is to write the entire problem solution in a single column.
|
|
|
|
|
Did you used to be active on the C++ Builder groups? I remember long ago I was working through code styles and one person had the following:
void someFunction() {
if (something) {
doThings();
}
}
The final hanging brace bothered me for a long time, but I adopted everything else because it had the greatest beauty and logical consistency of all the styles I'd seen. As I used it more and more I finally reached a day where the logic of the final hanging brace became perfectly clear, and I adopted it and never looked back! I agree with all the points you made - it is so much easier to grok the code when it has internal beauty, and doesn't take up tons of space!
|
|
|
|
|
That is the style I use except the closing brace closes below the opening keyword. I find the lone brace usually helps me to easily find where the braced sections end easily. Though for procedures with a lot of conditions, at the end the braces tend to run together.
I also only use two spaces per indent. It saves a lot of horizontal space.
void someFunction() {
if (something) {
DoThings();
}
else {
DoDifferentThing();
}
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
