Warming up

[niosus]

This is most definitely a pretty naive and probably a bit dumb question, but I'd like to get us started and to get a feeling how many people even reach this page, so here we go 😆

[HM102]

Designing real world code and applying design pattern.

[niosus]

That makes sense! I'm starting from the beginning, meaning that we have to cover all the basics, but we'll get to designing something pretty real towards the end. 👍

[yosoufe]

check this out: https://refactoring.guru/design-patterns/cpp

[fransay]

check this out: https://refactoring.guru/design-patterns/cpp

thanks for sharing!

[niosus]

@yosoufe I briefly looked through the link you posted and while I like the organization of the examples and articles I wouldn't say that they all follow the best practices. For example, the builder pattern uses a raw pointer, which I would not recommend do in modern C++, a unique_ptr would work much better there.

That all being said, I will definitely cover the patterns used the most in the course some time relatively soon. 👍

[fransay]

Is it helpful to always create new branches for different assignments?

[niosus]

I would say that it enforces a good habit even if it feels a bit excessive at first. Following the path of idea -> branch -> PR is in my opinion a very good starting point and makes life easier in the long run.

Do you have a specific problem with creating a branch per assignment?

[fransay]

Great, thanks for the feedback. I have no problem with initializing branches for each assignment, was thinking we might be generating a pile of them in our local git repo as the number of assignments grows steadily, but that is fine. I'm well OK!. I realised we can delete branches both remote and local as and when they are out of service.
Thanks. :-)

[niosus]

It should not be a problem. A good style is to delete the branch once it's merged into main anyway. If that is confusing, I could record an in-depth best practices with git video too. 😉

[fransay]

Got it, I'd love to see a video on the best practices of using version controls as well. I'm a fresh bachelor's graduate with a background in geodetic/geomatic engineering and a strong interest in photogrammetry and computer vision. I'm literally starting my career life and I think it will always be best to get abreast with good fundamentals coupled with the best practices. I'm on Igor!

[jayabrata97]

It should not be a problem. A good style is to delete the branch once it's merged into main anyway. If that is confusing, I could record an in-depth best practices with git video too. wink

It would be a great help.

[tridivb]

An even dumber discussion maybe, I realized that whenever you mention the Undefined Behaviour for variables, you never refer to it as Garbage Value. 😉 When I learnt C++ (right after Objective C I must mention) for the first time, my teacher always referred to such values as such. Did this terminology ever change or is it a thing that just came over from C and over time became known as UB?

Also, where do you stand between rebase vs merge? 😄

[niosus]

There are no dumb discussions 😉

Well, yes, they are garbage values because of the undefined behavior. The UB is the reason they are garbage 😬 I think these things can be used interchangeably when speaking about values in memory but I would say that UB is a more general concept that sometimes leads to garbage values in memory if that makes any sense.

As for merge vs rebase, you mean in git right? I never merge. I always rebase, squash the commits and maintain a linear history of the project. I have it in my plan to talk about it too but probably some time later, need to find the time to make this right 😬

[tridivb]

Yes, the question was for git. I have the same approach with rebase to maintain the linear history. I have never tried the squash commit though as I wanted to see the exact history of when a specific change was made. However, it makes sense for larger projects.

[niosus]

I wanted to see the exact history of when a specific change was made

Well, I think the squash philosophy comes when one starts to think about every pull request as a "unit meaningful change". Then it has to have a meaningful message that explains what it does and if that does not fit into this message then usually it's a good idea to break it into a couple PRs. There are multiple ways to think about it but i really like this one and it serves me well in practice also for smaller projects.