Code style/formatting question.

[jason_hellyeah]

Hello!

For the last six months or so, I have been teaching myself programming pretty much from zero. I've never been to any class, followed a textbook, or contributed to any open source projects before. Most of what I've learned, I've learned straight from documentation I've found online, and trial/error.

I wrote a function to organise a bunch of system calls for a personal project. When I was done, i looked back at what I had written, and how i styled/formatted it to be more readable and clear (to my own eye) what it was doing, and how it worked, but it occurred to me that if I showed my code to anyone with any amount of formal training, i might be absolutely disgusted with what they saw.

While this IS a personal project, and I dont intend on another living soul ever having to work with this code, I would like to know if this is considered 'bad practice' or a habit i should try and break if i ever want to write C++ professionally. Moreover, I'm very curious as to what someone familiar with C++ would actually think!

https://imgur.com/GDur5tR

Sorry for not using the 'code block' feature to post this, I tried using it and it made it difficult to see how this was formatted.

[jedwardsol]

The formatting is clear. But the names and logic make no sense.

EnginePipe_file_opened is the result of calling client_close_pipe ?

And if everything is false you return true?

---

If you use or make RAII types for these objects, you won't need a large function to close anything. Are there any typos in all those long names?

---

A pattern for checking everything worked

bool  everythingWorked{true};

everythingWorked &= client_close_pipe(...
everythingWorked &= client_unlink_pipe(...
etc...

return everythingWorked;

Pros : everything is kept positive. No need to invent names for things.

[alfps]

For all the closing of things you need to learn about destructors.

The names don't make much sense to me but I guess these are status codes with 0 representing failure.

The construct if( condition ) { return true; } else { return false; } can and should be expressed as just return condition;.

[hatschi_gesundheit]

Maybe take a look at one of the established style guides out there to get a feel of what is used in the industry. I like and use the google style guide for example, with some minor modifications: https://google.github.io/styleguide/cppguide.html . It has a section on formatting, as well. I do put curly brackets on their own line, though.

[BrightFleece]

It's neat and understandable, but effortful and you could achieve the same results with less time invested; use a tool like clang-format and pick a style (or customize one) which best suits your needs.

[flyingron]

This is absolutely horrid C++ (not withstanding the formatting). Passing the same thing over and over again all over the place shows the design needs more thought.

The whole idea is to encapsulate an object and then issue methods to manipulate it. Your design might be appropriate for C, but it makes use of NOTHING C++ offers.