My preference with code comments is all code functions (stored procedures, triggers, tables, views, etc on the SQL side, methods, classes and functions on the .NET side) should have a boilerplate. You don't need to have comments on each line of code, but as soon as you are doing something that is abnormal or that a new developer would be confused by OR that is against the defined coding standards, a comment should be in place. Like if you are using a SQL_Variant datatype, I want to know why you aren't using a proper datatype for that and it must be documented in the code. The exceptions to this rule are functions that are single line functions. In .NET these would be things like the getter and setter functions. On the SQL side, this would fall into functions that are extremely obvious as to what they do based on the name and the short piece of code that exists such as a function called "ToUnixTime" and "FromUnixTime" which you can tell are just converting back and forth to Unix time.
On the SQL side, my preference is to do boilerplates even on simple things. The main reason for this is for revision control. I know people will tell me that the revision control should be done inside a source control system and I don't disagree here. But when I am in "emergency" mode because the whole company is down due to a stored procedure change, I want to be able to see what was changed in a human readable format quickly to see if it IS due to the stored procedure or if some process changed around the same time and it is a process issue. The fewer places I need to dig to see what changed and why, the better. Source Control lets me roll it back, but if I see it was changed 2 weeks ago and the problem started this morning, it is obviously not related to the stored procedure change. But if it was the same date, I can see what was changed (like "changed calculation to use a parameter for the datetime instead of the current SQL datetime" and the problem is with some conversion on the datetime (dd/mm/yyyy vs mm/dd/yyyy for example), then I know the probelm is likely related to the stored procedure change).
As for visual studio vs ssms, that is a tough one. I see pros and cons to both. As a DBA, I spend more time in SSMS than Visual Studio. But as a developer (both SQL and .NET), I spend a lot of time in Visual studio as well. I like having different tools as it helps me (visually) to "switch" mindsets for developing. .NET coding is very different than SQL coding and having a visual cue as to which way I should be thinking is nice. I think if I did all my coding in Visual Studio, i would end up with a LOT of row-based operations being done in SQL and get stuck on the .NET side when I start coding up a loop and immediately start questioning why I am using the loop.
I think if I was strictly a SQL developer or strictly a .NET developer, then sticking in the correct mindset would be easy and the tools at my disposal would be trivial. I run into similar problems when I go from PowerShell to SQL or Bash to bat or even linux to windows... I need a visual cue to remind myself of what I am doing and why the command doesn't work. "cd.." on linux I always alias since I type that SOOOO often, but remembering "vim" vs "notepad" is a fun one when you load up the terminal. I find the more visual cues I can give myself (like the task bar being at the "top" on Linux and "bottom" on Windows) helps me keep things straight.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!