You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An API should just describe what you want to do, and not how to do it.
All start bar operations would need something like:
var statusBar = VS.StatusBar.Initialise() / await VS.StatusBar.InitialiseAsync()
gets the service and stores it behind the scenes
does any setup required
returns a disposable class instance so the whole thing can be wrapped in a using statement
allowing for automatic disposing
the internal Dispose() method could also be publicly exposed
in case the user has their own reason to not want/be able to use a using statement
Async Example
public async Task ShowStatusBar()
{
//===
// initialise a StartusBar instance to add parts to
// we shouldn't have to get a status bar service, store it ourselves and call arcanely named methods off it
// we shouldn't have to keep track of any implementation details at all
//===
using (var statusBar = await VS.StatusBar.InitialiseAsync())
{
// for creating/using an animation, it should be as easy as:
var animation = await statusBar.CreateAnimationAsync();
// with overloads for the different types of objects that can be added for separate animations
// one overload could take in an array/list of objects to be added to the animation
await animation.BeginAsync();
//when you're ready for the animation to finish
await animation.EndAsync();
//===
// further status bar operations could follow here, as the `startusBar` variable has not yet been disposed
//===
// for showing progress, it really should be as **_easy_** as:
var progressIndicator = await statusBar.CreateProgressIndicatorAsync();
await progressIndicator.ShowAsync(5) // or maybe SetStepsAsync(5)
// indicating there's going to be 5 steps
// displays progress indicator at 0%
// do step 1
await progressIndicator.UpdateAsync();
// displays 20% (1 / 5 * 100 = 20%)
// do step 2
await progressIndicator.UpdateAsync();
// displays 40% (2 / 5 * 100 = 40%)
// do step 3
await progressIndicator.UpdateAsync();
// displays 60% (3 / 5 * 100 = 60%)
// do step 4
await progressIndicator.UpdateAsync();
// displays 80% (4 / 5 * 100 = 80%)
// do step 5
await progressIndicator.UpdateAsync();
// displays 100% (5 / 5 * 100 = 100%)
await progressBar.HideAsync(); // or maybe ClearAsync()
// removes the progress bar
}
}
Of course it could also be await VS.Notifications.StatusBar.Initialise(), but personally I really don't think that Notifications is necessary, and just makes the code harder to read. People are not going to think "I want to add something to the start bar" and immediately try VS.Notifications. to find StatusBar.
I get the original intentions of grouping methods together, and not having a large amount of methods directly hanging off VS, but VS. helps the thought process of being able to say in your head 'Visual Studio, do this' or 'Visual Studio do that'. You wouldn't think 'Visual Studio, Notifications, do this'.
And the code reads so much better as:
var statusBar = VS.StatusBar.InitialiseAsync();
than:
var statusBar = VS.Notifications.InitialiseStatusBarAsync().
But that's just my 2c, I always strive for readable code.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'd like to suggest the following:
async
code in a method that can't be madeasync
Whatever the implementation ends up being, it shouldn't drive what the API looks like:
An API should just describe what you want to do, and not how to do it.
All start bar operations would need something like:
var statusBar = VS.StatusBar.Initialise()
/await VS.StatusBar.InitialiseAsync()
using
statementDispose()
method could also be publicly exposedusing
statementAsync Example
Of course it could also be
await VS.Notifications.StatusBar.Initialise()
, but personally I really don't think thatNotifications
is necessary, and just makes the code harder to read. People are not going to think "I want to add something to the start bar" and immediately tryVS.Notifications.
to findStatusBar
.I get the original intentions of grouping methods together, and not having a large amount of methods directly hanging off VS, but
VS.
helps the thought process of being able to say in your head 'Visual Studio, do this' or 'Visual Studio do that'. You wouldn't think 'Visual Studio, Notifications, do this'.And the code reads so much better as:
var statusBar = VS.StatusBar.InitialiseAsync();
than:
var statusBar = VS.Notifications.InitialiseStatusBarAsync()
.But that's just my 2c, I always strive for readable code.
Beta Was this translation helpful? Give feedback.
All reactions