|
Play stupid games, win stupid prizes...
|
|
|
|
|
If this happened to me in the USA, I would invoke the Fifth Amendment: The amendment in the Constitution that protects you against self-incrimination. That should work, should it not?
Get me coffee and no one gets hurt!
|
|
|
|
|
I dunno - but I doubt it. Wouldn't it be classed the same a you being stopped for running a stop sign, and the officer noticing a bong on the passenger seat?
"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!
|
|
|
|
|
Yes! You are probably right! 
Get me coffee and no one gets hurt!
|
|
|
|
|
you'd think I'd be better at making it accessible to other developers.
That is the part of coding where I really struggle, and one of the reasons why I tend to write here, to try and improve that.
One of the problems is the size of functions in my code, a byproduct of some limitations of mine due to a head condition I live with - and yeah it impacts my coding. On the other hand I don't struggle with functions that have a high cognitive burden attached to them. Where most people might break a problem down into its component parts in order to solve it, I tend to solve it as a unit. Personally, I understand the advantage to breaking problems down, but half the time it's done simply because the author didn't fully understand the problem when they started attacking it, but I digress. My functions are longer because I have trouble keeping track of things that are offscreen. I need to work with what's right in front of me or I almost immediately forget what I was working on, or at least important details of how to work with it. I can write a function and a minute later (not exaggerating) forget how to call it, and while it happens to most of us occasionally, it happens to me constantly. It's part of the nature of that condition I live with. So I try to keep the entire problem onscreen in front of me.
That leads to functions with high cognitive load, and sometimes difficult to decipher code, at least for others, but I find my own code easy to understand precisely because of all the stuff I was just talking about. With other people's code, the more it's broken out, the *less* I understand it, and I'm not talking about layers of abstraction necessarily, but simply dividing a problem into different functions and classes confounds me.
What do you struggle with?
Real programmers use butterflies
|
|
|
|
|
Obviously i struggle with KISS, because what i feel is easy to read might not be for everyone.
This especially hits if you use pretty fancy functionality of coding that someone hasn't seen yet.
In my WPF area that's even more aweful since people tend to look into the View.xaml.cs file, to find it empty.
Or one of the external collegues that did the fancy as hell s**t but nobody could read, nor understand it, so i had to rework that to a pattern well known.
Regarding SOC or breaking down problems, my approach is to solve the issue inside one function and as soon as i have to reuse parts of it i break them down, or if i want to add some good bunch of unit tests.
So i'd say i won't deny fancy code but i also prefer to know whats going there.
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? "This is my signature: " + Environment.NewLine + _signature
: "404-Signature not found");
|
|
|
|
|
See, I look at that and I immediately know what's going on. That's part of the problem. I can't really gauge my own code's readability because of things like that. Break that out into a couple of functions if you want to encrypt it from me though. 
EDIT: hahaha I was looking at your sig and thought that was what you were talking about with your final sentence. mea culpa
Real programmers use butterflies
modified 30-Nov-21 10:51am.
|
|
|
|
|
HobbyProggy wrote: Regarding SOC or breaking down problems, my approach is to solve the issue inside one function and as soon as i have to reuse parts of it i break them down, or if i want to add some good bunch of unit tests.
What does SOC stand for?
Regardless, I break down functions in much the same way as you. I don't have a problem with long ones. But I'll break a fragment out if it exists elsewhere and can therefore be shared, which means the code can slowly evolve into lots of small functions. If it can't be shared, I'll break it out if it definitely simplifies the flow of control. And because I greatly favor tests that are broader than unit tests, unit tests don't influence the decision.
|
|
|
|
|
Greg Utas wrote: What does SOC stand for?
Separation of Concerns
Well you know, i became a fan of unit tests. They do test those small tiny bits in all possible ways. If that is good i'll do an integration test to see if all of the tiny bits also work as expected together, then... well you probably know how the line goes up there.
Also a reason why i reduce directly usage of class A from class B by slipping interfaces in between.
The more you want to get confidence into your system doing what it should do, the more you need to test each possible track of events with all the possibilities.
I am still not, how could one ever, testing enough. We basically started to ramp up tests and coverage, but so far a ~1200 tests deliver the first 9% of coverage. At least i know in these bits that everything is going according to plan.
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? "This is my signature: " + Environment.NewLine + _signature
: "404-Signature not found");
|
|
|
|
|
Unit tests have their place. It's just that I mostly developed frameworks, which need to be exercised by non-trivial applications, which then become the primary tests. I've also been working on a C++ static analysis tool. It does many of the things that a compiler does, so my code base often serves as the test suite. But I also did some container templates, and they have unit tests.
If you want to read something heretical, these articles by Jim Coplien are worth the time:
Why Most Unit Testing Is Waste[^]
Seque[^] [sic]
|
|
|
|
|
Overthinking problems ( surely it can't be that easy ? ) and I tend to over engineer things ( the product is never really finished in my mind )
Documentation ? what's that ?
I could go on.
"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
|
|
|
|
|
Maybe it's cheating, and obviously this only works for personal projects, but I've found that submitting articles to codeproject is a fantastic way to document my code. It works for me because I enjoy writing, but I don't enjoy creating documentation, if that makes sense. I also think if i had to choose between a well written article that covered most of what I needed and a basic doxygen reference "documentation" based on code comments, I'd choose the former every time.
Furthermore, I've actually carried this over into some of my commercial projects (not using codeproject of course, but writing "articles" so that others can understand the code I wrote and it works pretty well if everyone is amicable to it)
Offered FWIW
Real programmers use butterflies
|
|
|
|
|
You are a very good article writer - on one of the digital streaming sites I use someone has just created a build to get a Logitech Media player on ESP32 devices
ANNOUNCE: Squeezelite-ESP32 (dedicated thread)
"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
|
|
|
|
|
I think my problem is over-polish my code... Make it super-effective and super-readable at the same time, and never finish it...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I've had some success with the "never finished" problem by implementing my own internal "code freezes" and thinking of my code in versions or phases. That way I don't ever have to "finish" it. I just create the next version, much like you'd do with an app. For me at least, this works because I don't feel like I have to get everything done on this version. I can decide "I'm going to freeze this version once it does X/looks like Y/is as fast as Z" and then I do it. And the things I want to do that I haven't done, I simply add to my TODOs for the next version.
Real programmers use butterflies
|
|
|
|
|
You mean there is code that is finished?  You surely must be joking.
My code is never finished because:
a. Just before finishing I found a better way to do it.
b. Customer added new requirements that need to be implemented.
c. Just had a new bright idea about something else to do (oh, my ADD is acting up again)
Kornfeld Eliyahu Peter wrote: I think my problem is over-polish my code...
That's a good line for the stupid interview question "What do you see as your weak points?"
Mircea
|
|
|
|
|
Mircea Neacsu wrote: "What do you see as your weak points?"
I would answer that with 'sweets and snacks' 
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I struggle with the build process. Or rather, haven't even bothered to learn enough about it so that I can start porting my code to Linux. Maybe someday, or maybe someone will offer to set up the necessary build environment! But if anyone can recommend a good reference, I'd appreciate it. About 800 files, a dozen static libraries, and specific compile and link options are involved.
|
|
|
|
|
I'm assuming C++ here, forgive me:
I think it depends on the toolchain you want to use.
It might be best to start it on windows. Having a build environment that mirrors your linux environment on windows will make it easier to build for both platforms.
You can use this to accomplish it - usually: Mingw-w64[^]
That way you can use things like gcc and clang under windows.
I like to use VS Code because it scans for your compilers automatically, and integrates with things like CMake and make.
The biggest deal will be to get your code to compile for clang and gcc
after that you should be able to use the same tools on both systems, as long as you're using something like CMake
Real programmers use butterflies
|
|
|
|
|
Yes, it's C++. Is there anything else?!
Right now I just use VS2017 and configure it to do the build. I'd have to look into Mingw-w64. Is there a 32-bit version? I often build for that instead.
Being able to use gcc and clang under Windows would be a big plus. Then there's the question of debugging on Linux. Moving to VS Code once building and debugging works sounds like a good choice.
I did look into CMake, but all of these things look like arcana to me. A seasoned witch would feel at home with them, but I'd have a lot of learning to do.
|
|
|
|
|
Yes, there's both 32-bit and 64-bit versions as I recall.
Debugging on linux with VS Code is pretty easy since it integrates with GDB, the GNU C++ debugger on linux.
You can actually build your windows code from VS code as well, so it might be worth switching over entirely.
Real programmers use butterflies
|
|
|
|
|
Shoot. I just realized something about your post. You're talking about building for 32-bit. I believe you can do so with 64-bit minigw as I'm near certain the 64-bit build of the compilers and linkers can create 32-bit executables. You specify the architecture with some switch, i forget what as I've only used it once or twice. maybe -arch? I'd have to google it.
Anyway, it would be worth doing some legwork, and using the 64-bit minigw on a 64-bit system assuming you can. Then you run your build process for both on the same machine.
The only downside to using Minigw is you don't necessarily get access to the latest compilers.
I don't really like CMake, or make for that matter. I'm one of those people that feels like if you need a make file should have structured your source differently, *unless* you have code generation in place as part of the build process, or unless you want to run your tests as part of the build process, and honestly, I think a shell script is easier to use and understand. I don't really understand the point of make and cmake except to make your build scripts cross platform, but if you really want that you could just use powershell for it these days. Too many tools, too much nonsense. Not my circus, not my monkeys.
Real programmers use butterflies
|
|
|
|
|
I misunderstood mingw-w64 to mean that the tool targeted 64-bit, not that it was a 64-bit application itself, which was silly of me. It makes sense that it would have a switch for choosing the target.
When you say "code generation in place as part of the build process", I assume you mean automatic code generation in the original language as the initial step, not just regular object code generation.
|
|
|
|
|
Yeah, I mean source code generation, not object code generation, if I understood you correctly. Like some applications parse things, and they'll use a parser generator tool as part of the build process to create the source files for parsing whatever it is they need to parse.
Real programmers use butterflies
|
|
|
|
|
I need "white" space ... else it looks like rambling prose without paragraphs.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
