• 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: August 19th, 2023

help-circle
  • Jetbrains vim mode gets pretty close. My current issues with it are that I can’t use the ctrl+o navigation to go back to previous location when using something like “Go to implementation” and import auto import is going to be the thing that’s loaded in to the “.” repeat action.

    I’ve tried basic vim and IDE setup vim but Rider has to many nice things like checking inline SQL strings against a database when programming C# and that sounds like a can of worms to set up. I tried Lunarvim and it was really good but Rider just has a better debug mode experience.

    It may sound weird but I don’t feel like maintaining my vim for couple of hours here just to have all the features of my current IDE. I still use Lunarvim on smaller projects or to edit some text and whatnot but for work I really prefer my IDE and all the bells and whistles that come with it. For example I have Ctrl+. to search for an action “history”+enter shows the git history of the current file. There are tons of these nice things.





  • More or less the same but the user gets passed as a method parameter each time. Validators would be in my opinion a long function inside the service also with named variables like this because it’s just easy to read and there are no surprises. I’d probably refactor it at around 5 conditions or 30 lines of validation logic.

    I recommend trying out using the constructor in services for tools such as a database and methods for data such as user. It will be very easy to use everywhere and for many users and whatever

    const passwordIsValid = ...
    if (!passwordIsValid){
      return whatever
    }
    






  • I always thought of the “how” being better explained by the code itself where you can see string.replace(" ", "\ ") as the actual fix while the message says the “why”.

    I would still have “Fix a bug where strings containing whitespace break CSVExporter” as my go to message.

    I guess our viewpoints are different based whether we want the commit messages to represent tasks or changes. They both have their uses of course. Looking at changes to a file to know what people have done to it is better with a “changes” type message but looking at the history to check “did we actually complete this or was it just marked as completed in the issue tracker?” is better with a task based message.

    Task management where every issue is put on a ticket and tracked would my type of messages obsolete but at my current company theyre very useful.