C# *

Вышел релиз OneScript 1.9.0, развивающий независимую от компании 1С кросс-платформенную виртуальную машину для выполнения скриптов на языке 1С:Предприятие. Система самодостаточна и позволяет выполнять скрипты на языке 1С без установки платформы 1С:Предприятие и специфичных для неё библиотек.

Виртуальную машину OneScript можно использовать как для прямого исполнения сценариев на языке 1С, так и для встраивания поддержки их исполнения в приложения, написанные на других языках. Код проекта написан на языке С#, распространяется под лицензией MPL-2.0, доступны сборки для работы в Linux, Windows и macOS.

OneScript поддерживает все возможности языка 1С, включая нестрогую типизацию, условные выражения, циклы, исключения, массивы, регулярные выражения, COM-объекты и встроенные функции для работы с примитивными типами. Стандартная библиотека предоставляет функции для работы с файлами и строками, взаимодействия с системой, обработки JSON и XML, сетевого доступа и использования протокола HTTP, математических вычислений, работы с макетами.

Изначально система OneScript 1.9.0 рассчитана на разработку консольных приложений на языке 1С, но сообществом развивается библиотека OneScriptForms, позволяющая создавать приложения с графическим интерфейсом. Кроме стандартной библиотеки и OneScriptForms для OneScript доступно более 160 пакетов с дополнительными библиотеками и утилитами. Для упрощения установки и распространения библиотек предлагается пакетный менеджер opm.

Источник: OpenNET.

Интересный вопрос. Что выведет данная программа? А скомпилируется ли она вообще?

var str = new TheBestStructEver(5);

Console.WriteLine(str.A);

public struct TheBestStructEver
{
    public int A;

    public TheBestStructEver(int a)
    {
        A = a;
        this = new TheBestStructEver();
    }
}

Ответ: Да, скомпилируется, причем без всяких предупреждений, и выведет 0.

Давайте разберем почему это так. Обратимся к IL-коду нашей структуры, а конкретнее к 12-ой строчке. Вот как она выглядит в IL-коде:

IL_0013: ldarg.0
IL_0014: initobj      TheBestStructEver

Итак, первая строчка загружает в стек нулевой аргумент, переданный в метод (конструктор - тоже метод). Аргумент под нулевым индексом - это указатель на объект, в котором мы работаем, то есть this. initobj инициализирует каждое поле структуры нулями или null по адресу, которое лежит у нас первым в стеке (а у нас там лежит указатель на this). Дополнительно мы еще передаем токен, который указывает тип структуры. Таким образом получается, что у нас вся структура "перезатерлась нулями" и значение поля A равно нулю.

TIOBE Software опубликовала январский рейтинг популярности языков программирования, в котором по сравнению с январём 2023 года выделяется перемещение языка JavaScript с седьмого на шестое место, языка PHP с 10 на 7 место, Scratch с 20 на 10 место (рост популярности на 0.83%), Go — c 12 на 11, Fortran — с 27 на 12 (+0.64%), Object Pascal — c 17 на 13, MatLab — с 15 на 14, Kotlin — с 25 на 17 и Cobol — с 31 на 20.

Языком года назван C#, который сохранил 5 место, но стал лидером по росту популярности (+1.43%).

За год снизилась позиция в рейтинге языков: Visual Basic — с 6 на 8 место, SQL — с 8 на 9, Ассемблер — с 9 на 15, Swift — c 11 на 16, Ruby — с 16 на 18, Rust — c 18 на 19 (при этом популярность Rust выросла на 0.18%).

Рейтинг продолжает возглавлять язык Python, но за год его популярность снизилась на 2.39%. Популярность языка C снизилась на 4.81%, C++ — на 2.95%, а Java — 4.34%.

Индекс популярности TIOBE строит свои выводы на основе анализа статистики поисковых запросов в таких системах, как Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube и Baidu.

В январском рейтинге PYPL, в котором используется Google Trends, тройка лидеров за год не изменилась: первое место занимает язык Python, далее следуют Java и JavaScript. Языки С/C++ поднялись на 4 место, вытеснив язык С# (год назад произошла обратная ротация). По сравнению с январём прошлого года выросла популярность R (+1), Rust (+1), Ada (+2), Dart (+2), Lua (+2), Perl (+1), Haskell (+1).

Именование юнит тестов

Мне всегда нравятся “информативные” названия тестов вроде “TestLogin”. 

Смотришь и из названивая в принципе не понятно, что именно мы тестируем.

В книге “Искусство автономного тестирования (The Art of Unit Testing)” предлагается следующий способ именования тестов: [UnitOfWorkName]_[ScenarioUnderTest]_[ExpectedBehavior]

• UnitOfWorkName — имя тестируемого метода либо группы методов или классов

• Scenario – условия, при которых тестируется автономная единица

• ExpectedBehavior – что должен делать метод при заданных условиях

Например, если мы тестируем вход пользователя с неверным паролем и ожидаем, что произойдёт ошибка, то названия теста может выглядеть так: TestLogin_InvalidPassword_ThrowsException.

Прочитал тут заметку про красоту замыканий и у меня появились смутные сомнения по поводу того, как появилось эта, в разных смыслах, положительных и отрицательных (я не к тому, чтобы встать на какую-то сторону, я за разумное разнообразие), хитрая техника построения кода.

В большинстве языков является естественным распространение области видимости переменных из внешнего блока во все внутренние блоки кода. Приведу пример, чтобы не было сомнений (псевдо-код намеренно нарушает синтаксис известных мне языков, чтобы не быть отнесенным явно к одному из них):

Function(type par)
{//outer block(see“inner block”father)
  Int X = 123;
  If(par == someConst)       
  {//inner block
	We can use X here!
  }
}

Определение для Лямбда-функции тоже создает внутренний блок кода:

Action Function(type par)
{//outer block (see “inner block” father)
  Int X = 123;
  If(par == someConst)       
  goto Label; //we need goto just to escape definition of extra inner block
  Return lambda=>
  {// inner block
  some code that uses X in the block
  };
Label:
  We can still use X here!
}

Интересно! Это только мне кажется, что передача переменных из окружающего кода в код Лямбда-функции, ВОЗМОЖНО, изначально была ошибкой при разработке компилятора, когда стандартный способ распространения области видимости переменных по недосмотру применили к вновь появившимся инлайн реализациям функций? Но потом кто-то нашел применение такой возможности и, как это часто бывает, «Бага»(bug) превратилась в «Фичю» (feature)?

Расскажите своё мнение: на чём актуально писать более-менее крупную софтину под windows?

Работаю в проекте, нужна программа контроля доступа сотрудникам. БД + GUI + работа с устройством (перезаписывалка RFID меток). Проект - студенчесский стартап, так что пишем сами, не используем интеграции с крупными решениями.

Встал вопрос на чём писать. У меня компетенций в равной степени хватает на QT + C++, .NET + C# или Electron + js. Поэтому сложно определиться, важна скорость разработки и количество гайдов. По скорости выигрывает electron, а по гайдам .net.

По особенностям - много различных по содержанию окон, возможность работы с usb устройствами.

Если Вы шарите в современной разработке программ под виндовс, дайте, пожалуйста, своё мнение, с удовольствием пообщаюсь в комментах.

Заранее спасибо!

P.S. Надеюсь не вызвал постом ощущение что я не желаю думать свой бОшкой, просто есть внутренний крик души, подумал, почему бы не посоветоваться с умными хабрятами)

​​Как тестировать internal методы и классы в C# — InternalsVisibleToAttribute

Представьте, что вы разрабатываете библиотеку, которой будут пользоваться тысячи людей ?. Чтобы убедиться в стабильности — нужно всё хорошенько покрыть тестами. Все мы любим инкапсуляцию, верно (я надеюсь)? Поэтому мы не разрешаем использовать всё подряд из нашей сборки, а с умом используем модификаторы доступа и позволяем использовать только public классы и методы. 

В C#, есть 7 модификаторов доступа, основные: 

- private —  доступ только внутри текущего класса

- protected —  доступ внутри текущего и дочерних классов

- public — классы и методы доступны где угодно, также из сборок, использующих текущую

- internal — публичный API, внутри текущей сборки. Как public, но нет доступа из сборок использующих текущую

- остальные можно посмотреть тут

Но, C# — не JavaScript, и для тестов создаётся отдельная сборка, а internal методы в ней не доступны.

Чтобы тестировать internal функциональность, нужно использовать атрибут InternalsVisibleToAttribute, и в качестве параметра указать имя тестовой сборки. Тогда все internal методы и классы будут доступны для тестирования.

[assembly: InternalsVisibleToAttribute("YourProject.UnitTests")]

https://t.me/cherkashindev/127