Short answer it depends on your needs and you comfort level with server management. But generally I would say a server running something like Jenkins or similar is not that taxing on the maintenance budget. It does have some up-front cost in getting everything configured and running as you like but after that it is fairly easy to maintain. I usually automate the provisioning as much as possible both for the self-documenting aspect but also to make it easier to repave the system or spin up additional nodes as needed.
And also, the code can be clear and tell the truth along with the comment, while still being unhelpful:
// Add with adjustment factor
function AddWithAdj(int a, int b) { return a + b + 12345 }
When the function was written, everyone probably knew what the adjustment factor was for and how it was determined, but years later, someone's going to look at that code and have no idea.
>When the function was written, everyone probably knew what the adjustment factor was for and how it was determined, but years later,
>someone's going to look at that code and have no idea
Well, to be fair that adjustment factor could be refactored to use a usefully named constant, with a helpful comment.
static const int ZEN_ADJUSTMENT = 12345; //When I wrote this only myself and God knew what this value meant, now...
int AddWithAdj(int a, int b) { return a + b + ZEND_ADJUSTMENT; }
static const int ZEN_ADJUSTMENT = 12345; //When I wrote this only myself and God knew what this value meant, now...
int AddWithAdj(int a, int b) { return a + b + ZEND_ADJUSTMENT; }
And now the maintainer is going to wonder why the originally programmer defined ZEN_ADJUSTMENT just above this function, but actually used ZEND_ADJUSTMENT (which is apparently defined somewhere else in the code). By design or typo!? :-)
Sure, but I don't think anyone would call this a useful comment - it's exactly the kind of comment which should be avoided.
Comments don't need to describe what the code does, but if there's an unexplicable line which handles an obscure edge case you better add a comment or even you won't remember why that line exists 3 months later.
Because comment is out-of-date. That’s technical debt. The comment is not the problem: the developer not updating it is.
You wouldn’t leave out-of-date code in a system, it would cause bugs. Why would you leave out-of-date comments? Oh, because you don’t like to write. Your strength is math and code, not writing. Now we get to the heart of the matter and not some ruse like “code is self-documenting.”
i mean, this is actually perfectly clear—in the sense it’s clearly and obviously a mistake either with the comment and function name or it’s implementation. the example isn’t great because it’s devoid of context that might indicate what specifically is wrong with it.
there are many standard means that should catch this: code reviews, unit tests, etc.
this stuff can obviously still sneak through, but i don’t think this is a good example of what folks are generally talking about here.
// Do does x, y, and z, in that order.
func Do(x, y, z func()) {
x()
z()
y()
}
Sometimes, as here, the comment correctly describes what the code should do. But the implementation does not agree with the comment. Relying on the comment, a developer can confidently fix the bug, or, at least, notice a discrepancy between the intentions, as described by the comments, and reality, as implemented by the lines of code. This is particularly important in complex code. Think: HTTP keep-alive handling, in which many factors, with varying priorities, have to be taken into account (e.g. client hint in the request header, current server load, overall server configuration, per handler configuration).
It’s also plausible that the function used to do x,y,z in that order, but then a new requirement came to do z before y. The code was changed, maybe a test was even added, but the comment was never fixed.
That’s the problem with comments (and all documentation really) - it gets stale and has no guarantee of being correct.
A better way is to write a test which would break if the order of x,y,z was wrongly changed. This way the order is guaranteed to stay correct forever, regardless of any comments.
I agree with your points regarding writing a test. It is one of the best ways, and the right way, to handle the issue.
That said, I think my toy example wasn't the best way to show some of the points I was getting at. Consider a real example, such as this function from file src/net/http/transport.go in the Go source:
// rewindBody returns a new request with the body rewound.
// It returns req unmodified if the body does not need rewinding.
// rewindBody takes care of closing req.Body when appropriate
// (in all cases except when rewindBody returns req unmodified).
func rewindBody(req *Request) (rewound *Request, err error) {
if req.Body == nil || req.Body == NoBody || (!req.Body.(*readTrackingBody).didRead && !req.Body.(*readTrackingBody).didClose) {
return req, nil // nothing to rewind
}
if !req.Body.(*readTrackingBody).didClose {
req.closeBody()
}
if req.GetBody == nil {
return nil, errCannotRewind
}
body, err := req.GetBody()
if err != nil {
return nil, err
}
newReq := *req
newReq.Body = &readTrackingBody{ReadCloser: body}
return &newReq, nil
}
When you work with code in or around this function, the existence of the comments tell you what the function guarantees, for example, regarding the closing of the request body. If at some point, there is a bug, it is more likely to be noticed because of the discrepancy between the intentions in the comment and the implementation in the code. Without the descriptive comment, an unfamiliar developer working on this code will likely not be able to tell if something is off in the function's implementation.
Also, as a user of code, it's nice to first know descriptively what guarantees a complex internal function promises from its comment. Then, if necessary, be able to verify those guarantees by reading the function body.
Of course, in an ideal scenario, a unit test is the best way to address things. But this this is a 22 line function unexported function in at 2900 line file, and sadly it appears this function isn't unit tested.
So, given how things are in practice, I argue that the presence of a comment, like here, can help with correctness of code.
Life, while being fragile and vulnerable, can also be extremely resilient.
My cousin and his girlfriend became pregnant a few years ago but the fetus were stuck outside the uterus, so the decision was made to have an abortion followed by a surgical cleansing (a scrape) to make sure nothing was left. The procedure was successful.
After the failed pregnancy my cousin's girlfriend started getting her period again but it was not as regular as it used to be. The doctors attributed it to the recent pregnancy/abortion which could cause irregularities in her hormonal balance etc.
So a while after all this happened, the girlfriend one night had what she believed to be gallstone pain in her stomach. She were familiar with gallstone attacks so that was the most logical explanation. Yet, she was sent to the hospital to have a checkup just to be safe.
You might have guessed it. The nurse at the hospital quickly figured out the cause of pain... She was pregnant and very much in labor. Of course this was 9 months after the abortion so it seemed impossible to her.
So apparently the abortion wasn't successful after all, as they overlooked a second fetus inside the uterus and also missed it while scarping the uterus lining.
So the girlfriend had to call up my cousin at work and tell him he was about to be a dad and that he had to come to hospital immediately. 4 hours later their daughter was born.
Are there any good options for me to switch to linux, if I'm forced to work on a windows project in visual studio 2022. I guess I can run a Windows VM but I fear performance degradation. Also I guess I could switch my IDE to Rider, but compiling to .NET Framework 4.8 would be impossible on linux I Guess (again It would be fine in a windows VM).
If you're thinking of setting up a program, it's worth your time to read over some existing program policies - those policies encapsulate a lot of experience that the existing programs have had on their platforms. Your ideal policy will probably differ, but it's worth thinking about why the other program policies are the way they are.
It's a 100.000 DKK limit. A Lot of people will be affected (not by much though). My girlfriend will have to pay about 300 DKK a year for having somewhere between 100k-200k in her account. I got my money in investments so I pay more than her in various fees, though I usually also make more while the market is climbing.
‘"But in fact, it's a sensor defect," he said. "In future processing when we further optimize this, this will be cleaned up and interpolated from nearby pixels. But for the moment, it's still clearly visible."’
As someone who worked in the very same municipality... one word; bureaucracy.
More specific reasons were. Legal boundaries between ownership and taxpayer money separation. Of cause GDPR is also a big obstacle in joining forces on this scale.
I worked on a project which tried to make a joined venture between several municipalities. I'm not sure if that partnership has ended yet, but overall you could only progress if there were people on both sides collaborating with a "better ask forgiveness, than permission" mindset. As soon as the municipality lawyers or their security officers got involved, all progress stopped immediately.
See this playlist: https://www.youtube.com/playlist?list=PLujxSBD-JXgnnd16wIjed...